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ABSTRACT 
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In this Thesis, two published algorithms dealing with 
deadlock detection in computer networks are discussed, and exam- 
ples demonstrating the failure of these algorithms are given. 
Two algorithms are then presented for detecting deadlocks in a 
computer network which allows processes to wait for 1) access to 
a portion of a database, or 2) a message from another process. 
The first algorithm presented is based on the premise that there 
is one control node in the network, and this node has primary 
responsibility for detecting process deadlocks. The second, and 
recommended, algorithm distributes the responsibility for 
detecting deadlocks among the nodes in which the involved pro- 
cesses and resources reside. Thus a failure of any single node 
has limited effect upon the other nodes in the network. A com- 
puter model of the "decentralized 11 (second) algorithm was de- 
signed and it is described in the Thesis. 
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I. Introduction 
A simple example of deadlock (or "deadly embrace") occurs 
when a process P1 is blocked while waiting for access to resource 
R2 which is controlled by process P2, and P2 in turn is blocked 
while waiting for access to resource R1 which is controlled by 
P1. A deadlock may involve more than two processes. For exam- 
ple, process P1 may be waiting for access to resource R2 which is 
controlled by process P2, P2 may be waiting for access to 
resource R3 which is controlled by process P3, ..., process 
P[n-1] may be waiting for access to resource Rn which is con- 
trolled by process Pn , and Pn may be waiting for access to 
resource R1 which is controlled by P1. 

Multiprocessing and data sharing are commonly used in a 
single location transaction oriented computer system. In the 
future they will be common to transaction oriented, geographi- 
cally distributed computer networks. In this Thesis an algorithm 
is presented that can be used to detect deadlocks involving pro- 
cesses waiting for access to a shared portion of a database or 
waiting for a message from a process with which it is 
communicating within a computer network. It is possible that a 
process can be either computerized or manual, although a manual 
process (i.e. a person at a terminal) can not directly request 
access to a portion of a database, as it is restricted to only 
communicate with computerized processes by the use of messages. 
Throughout this paper, the word "operator" will be used to refer 
to a manual process. 



Much has been written dealing with deadlock detection, 
avoidance and prevention In computer systems. However, most of 
the literature discusses a single location facility where the 

status of all processes and resources are available in a single 

I" i 

local table. (For a good discussion, including a graph model of 
computer systems which can be used to detect deadlocks, see "Some 
Deadlock Properties of Computer Systems*' CT1.) Very few articles 
have been published that are concerned with the deadlock problem 
in a computer network (geographically distributed computer 
system) . 

When dealing with a computer network mm opposed to a single 
location facility, the deadlock detection problem becomes more 
difficult due to the fact that all the information needed to de- 
tect a deadlock is not necessarily available in a single node, 
and communication delays may lead to synchronisation problems in 
getting an accurate view of the network state. Some reasons for 
restricting access to portions of a database (even though the 
result of blocking processes can lead to deadlock) and some rea- 
sons why the common deadlock prevention and avoidance algorithms 
are not well suited to the networks under consideration will be 
discussed. Several deadlock detection schemes for computer net- 
works (some from recent literature, some designed by this author) 
will be presented, and they will be followed by a discussion of 
some of the benefits of using the various schemes. 



1.1 The Interference Problem 

Given two or more independent processes, interference is 
said to have occurred if the results produced by their concurrent 
execution would not have been obtained by running these processes 
one at a time in any order (i.e. nonconcurrently) . 

A simple example of interference is the following. Let two 
processes, P1 and P2, read the contents of database record R1. 
Then let P1 add 5 to the value and let P2 add 10 to the same 
value. Mow let each process alter the contents of R1 to contain 
the value computed by that process. Depending upon the order of 
update, the contents of R1 will be either 5 or 10 greater than 
the value that was contained during the reads. We have a case of 
interference because the value of R1 would have been 15 greater 
than the value contained at the time of the first read if P1 and 
?2 had been executed sequentially in either order. 

Another case of interference occurs when a process, in pro- 
cessing one transaction, twice alters the contents of the same 
database object and in between the two writes, a second process 
reads the contents of that database object. In some cases a 
process which is only reading the contents of a database object 
may not care if there is any interference, in which case it may 
request "dirty read" access to the database object. (A process 
that is only reading the contents of a database object can not 
interfere with the values produced by another process, although 
other processes can interfere with the values produced by the 
"reading" process.) 



When maximum concurrency among independent processes is de- 
sired, a process must be allowed to read and alter the contents 
of a database object whenever it wants to. (This type of access 
to data has been called "shared rtad/shared write".) In order to 
detect interference, records must be kept about the type of use 
(read or write) of each database object, and what processes (and 
when they) used it. An algorithm to detect interference when 
this information is kept is presented in "On Managing Interfer- 
ence Caused by Database Sharing" [103. A more thorough discus- 
sion of interference is also given. After an interference 
situation is detected, at least one of the involved processes 
must be forced to rollback to a previous state in order to cor- 
rect the interference condition. 

Most systems, in order to avoid interference and guarantee 
that a process will see a consistent state of a database, 
restrict access to data by a system of locks. If a process wants 
to change the contents of a database object, it must request ex- 
clusive access to thst database object, thus temporarily (for the 
duration of the lock) preventing all other processes from 
accessing that database object. If a process only wants to read 
the contents of a database object, it can request shared read 
access to that database object, thus temporarily (for the dura- 
tion of the lock) preventing all other processes from altering 
the contents of that database object. If a database object can 
be shared among several readers, the method of access is called 
"shared read/exclusive write", whereas if there can be only one 
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reader, it is called "exclusive read/exclusive write". 

When a request for access to a database object (resource) 
can not be granted due to the existence of a lock on that 
database object, the requesting process must be blocked until the 
resource becomes available. Due to processes waiting for access 
to resources, there exists the possibility of deadlock among the 
processes in a computer system. 

1.2 Deadlock Prevention 

Deadlock prevention schemes place constraints upon system 
users in order to ensure that deadlock will never occur. There 
is little operating system overhead involved when using 
prevention methods. There are several deadlock prevention algo- 
rithms that are widely known: 

1. Each process must request all needed resources at one 
time and will remain blocked until all requests can be 
granted simultaneously. (This is often referred to as 
"static" allocation.) 

2. All resources are given a unique number and processes 
must request resources, one at a time, in numerical or- 
der. 

3. When an active process requests a resource that is con- 
trolled by a blocked process, the blocked process must 
release the resource so that it may be allocated to the 
active process. A process will go from the active to 
blocked state only if it requests a resource controlled 
by another active process. 

The unpredictability of resource usage in a transaction 

oriented system, plus the loss of productivity that results from 

tying up resources unnecessarily or forcing processes to release 

resources and request them later (which often results in some 



redundant computations due to a process having to repeat some 
operations to maintain a consistent database) make prevention 
algorithms undesirable for use in the systems under considera- 
tion. In a multiprocessing environment which considers 
inter-process messages as resources, it is impossible to have an 
advance knowledge of all the resources that will be needed by a 
process. Thus algorithm 1 can not be used in this type of sys- 
tem, whether it is a single or multi node facility. Algorithm 2 
is unsuitable for the systems under consideration because al- 
though it may be possible to give a unique number to each 
inter-process message, a process must be "allocated" each message 
that it will lend to another process, which caff result in many 
difficulties when two processes are sending several messages to 
each other. Algorithm 3 can not be used becetise it implies that 
all resources must be pre-empts bl# (i.e. they muSt be able to be 
released by a process upon the demand of the system) , which is an 
impossible situation when messages arc treated as resources. 

1.3 Deadlock Avoidance 

Deadlock avoidance algorithms calculate safe paths for com- 
pletion of all processes. Before a resource is allocated to a 
given process, the operating system checks if there would be at 
least one path via which all processes can run to completion 
after the allocation is made. If no such psth exists, then the 
requesting process must wait until a time when the resource can 
be safely allocated to the process. Avoidance algorithms thus 
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force processes to wait unnecessarily in order to be certain that 
all processes will be able to run to completion without the 
threat of deadlock. 

In "System Deadlocks" [5] it is stated that "to avoid 
deadlocks in a multiprogramming system in which the necessary 
conditions for deadlocks can exist, it is usually necessary to 
have some advance information on the resource usage of tasks." 
When portions of databases are considered resources, and they are 
locked at a level lower than a file (page, record, field, etc.), 
it is difficult to determine in advance what database objects 
will be needed. In addition, due to the unpredictability of 
processes in a transaction oriented system, it is impossible to 
have an advance knowledge of all the inter-process messages that 
will be requested by a process. Therefore, deadlock avoidance 
algorithms can not be used in a single or multi node transaction 
system which permits inter-process communication. 

1.1 Deadlock Detection 

Since it seems that deadlock prevention and avoidance algo- 
rithms are unsuitable for the distributed systems under consid- 
eration, deadlock detection methods must be examined. When 
employing a deadlock detection algorithm, requested resources are 
usually assigned to the requesting processes whenever possible, 
and processes are blocked only when desired resources are 
unavailable. Either the operating system or a system user must 
occasionally check for a deadlock situation, and if one is found, 
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must rollback (backup) and retry at least one process in order to 
break the deadlock. (It is hoped this will force a new sequence 
of access to resources.) 

From the implementor's viewpoint, the easiest strategy to 
adopt is that where one assumes deadlock occurs infrequently. In 
this case someone (an operator) external to the network would 
have the responsibility for detecting the deadlock and deciding 
what process should be forced to rollback to a previous state. 
With this approach the only overhead involves the temporary 
inahility to access the resources controlled by the deadlocked 
processes and the cost of rollback/retry of some, (or all) of the 
deadlocked processes. (This cost may be large for each deadlock, 
but if there are few deadlocks the overall system cost may be 
less than it would be if there were a "deadlock detector" that 
was constantly checking for deadlocks.) One could also assume 
that if a process has been blocked for *X* units of time, then it 
is deadlocked and the operating system should force it to 
rollback to a previous state, although this strategy may result 
in some unnecessary redundant computations because some processes 
that will be retried may not have been involved in a deadlock. 

At least two articles ha-#e been published which propose 
protocols for allocating database objects in a computer network 
in a manner such that deadlock can he detected at the time a 
request for access is denied. In designing an algorithm to be 
used to detect process deadlocks in a transaction oriented com- 
puter network which allows process to process communication, it 
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is necessary to allow for the possibility of a process waiting 
for a message from another process (which may be manual or 
computerized). Additionally, a process must be allowed to wait 
for access to a database object which has been allocated to at 
least one other process. 

Any algorithm that will be implemented as part of an oper- 
ating system should be as efficient as possible. Therefore, in 
the algorithms proposed by this author, an attempt was made to 
minimize the number and size of internodal messages involved in 
the detection of deadlocks. 

1.5 Structure of the Thesis 

Chapters II and III contain descriptions and comments 
(including some examples pointing out deficiencies) relating to 
two papers that have been published proposing protocols for 
allocating database objects in a computer network such that 
deadlock can be detected at the time a request for access to a 
database object is denied. Chapter IV presents an introduction 
to the two schemes for detecting deadlock in a computer network 
that are proposed by this author in Chapters V and VI. The two 
schemes differ in that one (Chapter V) places the primary re- 
sponsibility for detecting deadlock anywhere in the network on 
one control node, whereas the other totally distributes the re- 
sponsibility throughout the network. Chapter VII contains a 
discussion of a functional model of the algorithm proposed in 
Chapter VI. The Appendices contain a description and demonstra- 
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tion of the model, in addition to containing the PL/I code for 
the model itself. Chapter VIII contains some suggestions for 
future research, and Chapter IX contains a comparison of the 
various algorithms presented in Chapters II, III, V and VI, plus 
some concluding remarks. 

If one only wants to read about the algorithm that is 
recommended by this author, it is possible to read Chapters IV 
and VI with no loss of understanding. Chapter VII can also be 
understood after reading Chapters IV and VI; as can the Appendi- 
ces and some portions of Chapter VIII, 
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II. Proposal of Chandra, Howe and Karp 
In "Communication Protocol for Deadlock Detection in Com- 
puter Networks" [3], a scheme is presented which the authors call 
"a novel solution to the deadlock problem in the network 
environment." Their "solution" is described below, and the de- 
scription is followed by an example where the scheme allows a 
deadlock to go undetected. 

II. 1 Chandra, Howe and Karp's Proposed Solution 

The authors propose that each installation (node) maintain a 
resource table (RT) which contains information about which pro- 
cesses have been allocated local resources, which processes have 
been queued (waiting for access) for local resources, which local 
processes have been allocated remote resources and which local 
processes have been queued for remote resources. The type of 
access requested by each process is also recorded. The authors 
claim that in a single node facility, there are several well 
known algorithms for detecting deadlocks using the tables 
mentioned above. They then state "it is believed to be obvious 
that these same algorithms would suffice in the multiple instal- 
lation case provided that the resource table were to be expanded 
to include the pertinent information from the remote sites." A 
scheme to expand the resource table in a node is given in the 
paper. 

The authors believe there are three types of requests for 
resources that can lead to deadlock. (In all cases, "it is as- 
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sumed that the requested resource is not available, because, if 
it were, the allocation would take place immediately.") The ac- 
tion taken for each type of request is the following (as stated 
in the paper) : 
Case 1 

A process requests a local resource, which is allocated 
to a local process, and all of the processes which are 
queued for this resource are also local processes. All of 
the necessary information is contained in the local RT, and 
the request is resolved locally. 

Case 2 

A process requests a local resource, which is either 
allocated to a remote process or one or more of the pro- 
cesses that are queued for this resource are remote 
processes. In this case, all of the RT's must be obtained 
by the local installation since deadlock may occur. Once 
all of the RT's have been obtained, the 
deadlock-determination algorithm can be applied to the 
expanded RT which contains all of the resources and pro- 
cesses in the total community of installations. 

Case 3 

A process requests a resource at some remote installa- 
tion. In this case, the requesting installation forwards 
the request and its RT to the installation which has the 
requested resource. This installation then determines if 
the request can be honored immediately or if all of the RT's 
must be first obtained. In the case where the requested 
resource is allocated to or queued by only processes local 
to the two involved systems, the request can be honored im- 
mediately. Otherwise, this installation obtains the RT's 
from the remaining installations and then resolves the 
request. 

In all of these cases, the RT's that are involved in 
the decision procedure must be locked until after the deci- 
sion has been made. If the decision involves the RT's of 
the other installations in the community, these installa- 
tions must be notified after the decision is made and their 
table is then released. In Case 3, the updates to the RT 
must be returned to the requesting installation while all 
other tables can be discarded and a simple release notice 
returned. 
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A description is given of the actions to be taken when "two 
or more installations may simultaneously request the various RT's 
in order to make an allocation for two or more independent 
requests." 

II. 2 A Fault in the Proposed Solution 

There are some resource requests which fall under Case 1, 
and result in a deadlock for which the local RT does not contain 
enough information to detect. Consider the following example: 

Let the network consist of two nodes, A and B. Let 
processes P1 and P2 and resource R1 be local to A, and let 
processes P3 and PU and resources R2, R3, and R4 be local to 
B. Assume the following state of the network. (Figure 
II. 1a contains a diagram of this "intermediate" state.) P1 
has exclusive control of R1 and is queued waiting for access 
to Rit, P2 has exclusive control of R2 and is queued waiting 
for access to R1, P3 has exclusive control of R3 and is 
queued waiting for access to R2, and PH is active 
(non-blocked) and has exclusive control of R4. In this 
state there is no deadlock. Now let P4 request access to R3 
and be queued for the resource. A deadlock now exists (see 
Figure II. 1b) involving all four processes and all four 
resources. With the tables as described in the article, 
this deadlock could not be detected unless node A sent node 
B its tables, but this does not take place because the 
request falls into Case 1 (since P4 is local to B, as are P3 
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and R3). Therefore the deadlock goes undetected. 

Similar examples (for networks consisting of three or more 
nodes) exist where requests falling under Case 3 result in 
undetected deadlocks. RT's from 3 or more nodes may be needed 
even if "the requested resource is allocated to or queued by only 
processes local to the two involved" nodes. 
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Intermediate State Diagram 
Figure II. 1a 




Final State Diagram 
Figure II. lb 



() Represents a process 

1 | Represents a resource 
LJ— *\_) Represents a process having exclusive use of a resource 
rjV-->l I Represents a process waiting for access to a resource 
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III. Proposals of Mahmoud and Riordbn 
In "Protocol Considerations for Software "Controlled Access 
Methods in Distributed Data Bases" [8], two schemes are presented 
for allocating database files in a network environment. The 
authors (Professors at Carleton University, Ottawa, Ontario, 
Canada) claim that with their schemes, by using the graphic rep- 
resentation as described in [9], deadlocks ein be detected at the 
time an allocation decision is made. The two schemes are de- 
scribed below, and a brief discussion about the schemes follows, 
including an example where one of the proposals allows a deadlock 
to go undetected. 

The first approach described requires fchat all deadlock 
tests be made by one node, whereas with the second; approach each 
node must test for deadlock resulting #p«mHdl€ferent processes 
accessing its files. Each node in the network will contain a 
Distributed Data Rase Management Facility (DD8MF) which will 
communicate with -the other DDBMF processes in the network for the 
purpose of handling requests for local and remote processes. 

III.1 Mahmoud and Riordon' s Centralized Control Approach 

In the centralized approach, one node, called the control 
node, will make all the deadlock tests and handle all file 
allocations. If a process running at node i would like access to 
a file in node J, a request is sent to the D0BMF in node i, which 
then relays it to the central DDBMF, even if node i and node j 
are the same. Since the central DDBMF makes all the file 
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allocation decisions, it has an overall picture of the global 
network status, and can therefore decide if the request can 
safely (without deadlock) be placed on the file queue. 

III. 2 Mahmoud and Riordon's Distributed Control Approach 

In the distributed approach, the DDBMF at each node will 
have full control over all access to the files located at its 
node. As a result of this, the authors state that "each node 
DDBMF will be responsible for handling job interference 
(deadlock) problems that may arise while different processes are 
accessing its files." In order to avoid or detect deadlocks 
involving processes and files located at two or more nodes, "each 
individual DDBMF must obtain information from other DDBMF pro- 
cesses indicating the status of their files and queue tables. 
The information will be used ... to construct a global picture of 
the network and thus enable each individual DDBMF process to make 
the correct decisions." 

All active user processes are separated into two classes. 
In the authors' own words, 

The classification is based on the localities of the files 
requested by the process and the type of access to each of 
these files: 

Class 1 : each process belonging to this class has the fol- 
lowing properties: 

1) All files accessed by the process during its active 
session are located in a single node. 

2) All files being updated by the process are single-copy 
files in the network (i.e. only a single copy of each 
file exists in the network). 

Class 2 : each user process belonging to this class has the 
following properties: 

1) Files that are accessed simultaneously by the process 
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during an active session do not all exist in a single 
computer system and/or 
2) Any one of the files being updated by the process has 
multiple copies In the network. 

It is obvious that the two classes of processes are 
mutually exclusive. 

The authors suggest using a graph representation in order to 

detect deadlock, and they describe how a DDBMF gets information 

from the other DDBMF' s in the network emd when it should check 

for deadlock: 

Assume that there *rm n node* in the network, i.e., n 
individual DDBMF processes. Each process will transmit 
(n-1) identical messages simultaneously, with one message 
addressed to each of the remaining DDBMF processes. Each 
message contains the. most updated information about the 
status and queues of files at the node In question. The 
messages will be transmitted periodically at the onset of 
synchronous clock intervals. Similarly, each DDBMF process 
will receive periodically (n-1) messages fro« the other 
processes. Now assume that a btimfr process receives a 
request for access to one of the files under its control 
from a local or remote user process. If the i requesting 
process belongs to class t, the DDBMF will respond immedi- 
ately to the request. Otherwise the W9M$ will delay action 
until the next time interval, i«e* i: it|itil receiving updated 
information about the status of the network files from other 
DDBMF processes. The request is then checked against any 
possible Interference (deadlock) and the user process is 
notified once s decision Is made* i 

Requests which can not be acted upon until the next time 

interval are placed in a pre-test queue. ] 

At the beginning of a clock interval, each processor 
receives information from other processors including the 

contents of the file queues *nd ,-*%t ;#£e*^e»t .o.ueue r - The 
processor extracts the contents of the, fip^e>MMNim queues and 
combines them to construct ..4 gl©b»4 pre-test queue which 
includes all the request* for -fil#':«j&ie«aah:: : re«Wi*«4. by all 
processors during the : orevioa* time ji**t«r*#l'. -; The file ac- 
cess requests Jon the global pre-teat queue are tested for 
deadlock conditions and decisions*. -are-? stheii made. 

To avoid deadlock situations caused by critical race 
conditions, the file access requests on the global pre-test 
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queue must be arranged in the same order in all 
processors... All processors must then follow a predefined 
routine in constructing the global pre-test queue. The 
resulting versions of the global pre-test queue will be 
identical in all processors at the beginning of every clock 
interval . 



III. 3 Some Comments about the Proposed Schemes 

The authors state that their schemes will work if records, 
or other units serve as the identifiable unit of object data, 
rather than files, which were mentioned throughout the paper. 
When records are allocated individually, there will be more mes- 
sage traffic due to additional message requests for access to 
database objects. Nowhere in the paper is the problem of message 
congestion at the control node (when using the Centralized 
approach) discussed. With all requests for access to database 
objects being handled by the central DDBMF, there exists the 
possibility of a message bottleneck at the control node, which 
would degrade network performance due to slow response to the 
requests. 

It is mentioned that failure of the control node (when using 
the Centralized approach) can "paralyze the operation of the 
whole system," although all the DDBMF's can send all their in- 
formation to another DDBMF, thus recreating the global picture of 
the system at a newly designated control node. Although the 
author's Centralized approach may be "inefficient," it can be 
used to successfully detect all process deadlocks when only waits 
on database objects are involved. 

The Decentralized approach, as described in the paper, does 
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not detect all deadlock situations when only process waits for 
database objects are involved* Consider the following example: 

Let the network consist of two nodes, A and B. Let 
processes P1 and P?, and files F1 and F2 be local to node A, 
and let processes P3 artd PI, and files F3 and FM be local to 
node B. Assume the following state of the network. (Figure 
III. la contains a diagram for this "intermediate" state.) 
P1 has exclusive control of Ft and is queued waiting for 
access to F*», P2 is active (no«»blo%ked) and has exclusive 
control of F2, P3 has exclusive control of F3 and is queued 
waiting for access to F2, and Ptf is setlve and has exclusive 
control of F«. Pi and P3 belong to class 2, as defined by 
MahfRoud and Riordon, and P2 and P* both belong to class 1 as 
long as each does not request access to a file located in a 
node other than the one in which the process resides. 

Now, within the same time interval, let P2 request ac- 
cess to F1 and let PM request access to F3, thus creating a 
deadlock because neither file can beeon« available. (Figure 
111.1b contains the final stata diagram for this deadlock.) 
P2 and P4 remain class 1 processes, and therefore these 
requests should be acted upon Immediately and each node will 
check for deadlock using the information that it has. No 
deadlock will be detected because 'fife It bar node has the in- 
formation about the recent request in the other node, and no 
provisions are stated in the article which imply that 
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deadlock involving P2 or P4 will be checked for at the onset 
of the next synchronous clock period. 

The authors believe that class 1 processes do not contribute 
to deadlocks that involve processes waiting for files located in 
wore than one node, and therefore deadlock can be checked for 
using only the information located at one node when a class 1 
process requests access to a file. It is this assumption that 
leads to the downfall of their Decentralized approach, because it 
is possible that a class 1 process will request access to a file 
controlled by a class 2 process, resulting in a deadlock (as 
shown in the previous example) involving processes which are 
collectively waiting for access to files located in two or more 
nodes. Note that this is similar to the flaw in the protocols 
for deadlock detection proposed by Chandra, Howe and Karp. 
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Iflt«r*e4iat« Stat* Diagram 
Figure III* la 





Final State Diagram 

Figure III.1b 

KEY 

(j Represents a process 

I I Represents a file 

I l~\_J R eP«*esents a process having exclusive use of a file 
r^V-»l | Represents a process waiting for access to a file 
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TV. Introduction to Proposed Solutions 
The deadlock detection schemes that are presented in 
Chapters V and VI are based on the creation and expansion of or- 
dered blocked process lists (OBPL's) and the restriction that a 
process may only have one unapproved outstanding resource request 
(and therefore be waiting for at most one resource at any 
instant). A resource may be any non-ambiguously defined portion 
of an object, whole object, or collection of objects which are 
requested as an entity and released as an entity by all users. 
(The case where there are several equivalent resources like tape 
drives is not considered. A discussion of physical devices oc- 
curs later in this chapter.) An OBPL is a list of process names, 
each of which (with the exception of the last process in the 
list) is waiting for access to a resource that has been assigned 
to the next process in the list. Each process name in the list 
is often referred to as a process entry in the OBPL, and when an 
OBPL is sent between nodes, a resource name is inserted into the 
single resource identification portion of the OBPL. The last 
process to have an entry in the OBPL is either waiting for access 
to the resource named in the resource identification portion, or 
it already has access to that resource. In the former case, it 
must be determined what process controls the resource, whereas in 
the latter case, the state of the last process in the OBPL must 
be determined. 

It is assumed that at each node there is a process manage- 
ment module (PMM) which will handle deadlock detection and 
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resource allocation. It will maintain local state tables which 
will contain information about local resources (resources which 
are located in that node) and local processes (processes which 
are running in that node). If a PMM is checking for deadlock, 
and it is examining the OBPL with process entries P1, P2, ..., 
PN, then it knows that each process in the list (with the 
exception of PN) is waiting for the next process in the list to 
release a desired resource. If PN is not blocked, there is no 
deadlock and the OBPL can be discarded. If it is blocked, then a 
PMM must find out what process has been allocated the resource 
for which PN is waiting. If this process already has an entry in 
the OBPL, there is a deadlock, otherwise a PMM must append the 
process name to the OBPL and repeat the above. The schemes that 
are being proposed differ from each other in the way the OBPL's 
get expanded. 

IV. 1 Descriptions of Resources 

There are three types of resources that a process may wait 
for where the blocking of the process can result in a deadlock. 
They are database objects, message text from other computerized 
processes, and message text from operators (manual processes). A 
distinction is made between message text from processes and mes- 
sage text from operators because a deadlock which involves no 
operator messages can be detected without operator interaction, 
whereas if a process is waiting for message text from an opera- 
tor, a deadlock can not be detected without the operator stating 
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what he/she is waiting for. The reason for the latter point is 
that an operator typically does not type in "receive message" 
statements, but accepts output as it is given. In the algorithms 
presented, it is assumed that an operator can only wait for a 
message from a process with which he/she is communicating (a 
discussion of operator and process communication is given later 
in this section). This restriction can be relaxed, and it is 
discussed in Chapter VIII. 

Database objects, as discussed in this paper, can be fields, 
records, files, or any other logical or physical component of a 
database. It is important that all processes treat the same 
portion of a database identically for the purposes of allocation. 
The level of granularity (which may vary for different database 
objects) at which database objects are allocated is unimportant 
for the detection of deadlock; it does however, affect the 
frequency of deadlock and, conversely, the burden of maintaining 
information about resource allocation. 

Message text must be treated differently from database ob- 
jects because once a message text has been assigned to a process, 
it is not available to any other process. In this sense, once a 
message text has been assigned, it no longer exists for future 
assignment. To ensure that a process receives the proper message 
text, the sending and receiving processes must create a unique 
connection over which message text between the two processes may 
pass. When a process would like to receive message text, it must 
state over which previously established connection the text 
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should come. Similarly, when a process wants to send message 
text, it must Rive the message text and name the connection over 
which the text should pass. All messages that are sent and 
received over a given connection will be referred to as text 
within a specific message group. 

When message text is sent by a process, it is queued for 
receipt at the proper destination end of the connection. A pro- 
cess may send several items of message text over a given connec- 
tion before any messages are requested by the other process as- 
sociated with the connection. In this case the items of message 
text are queued for receipt in a first in, first out manner. It 
is assumed that message management has infinite queueing 
capacity, and therefore the possibility of a deadlock involving a 
process which wants to send a message but is blocked because 
there is no place to put the message text will not be dealt with. 

Unlike process to process messages, which may be sent be- 
tween nodes, when a process and an operator communicate, they 
must be located at the same node. Similarly, however, an 
"operator connection" must be established between the operator 
and process before message text can be sent over the connection. 
The operator connection must be specified when message text is 
sent or received over the connection. When messages are sent 
from a process to an operator, they are usually printed immedi- 
ately at the operator's terminal. However, messages that are 
sent from an operator to a process are queued for receipt in the 
same manner as process to process messages. 
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All of the resources described above are uniquely identifi- 
able, and are allocated dynamically (i.e. during the execution of 
the process requesting access to the resource) . None of them are 
physical devices (tape drives, printers, etc.), which are often 
not uniquely identifiable (there may be N of a kind). Physical 
devices are not considered by the algorithms that are being pro- 
posed because they are typically allocated to a process before 
execution begins and the known networks restrict processes to 
requesting physical devices at the same node. (If a process 
wants to control a physical device at another node, it must do so 
indirectly through a process located at the same node as the de- 
sired device.) Additionally, transaction oriented processes 
typically do not use dedicated devices. 

IV. 2 Access to Resources and the Blocking of Processes 

A process may get blocked when it requests read only 
(shared) access or exclusive (read/write) access to a database 
object. While one process has exclusive access to a specific 
database object, all requests for access to that database object 
result in the requesting process being blocked. While at least 
one process has shared access to a specific database object, all 
requests for exclusive access to that database object result in 
the requesting process being blocked, and requests for shared 
access to that database object will result in the requesting 
process being blocked or being granted access to the desired 
resource (depending upon the resource allocation scheme in use). 
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Because data values are not changed when a process only reads a 
database object, any number of processes may be allowed to have 
concurrent read only access to a database object. When all pro- 
cesses that had shared access to a given database object have 
released it, or when a process releases a database object from 
exclusive use, at least one process will be awakened and granted 
access to the newly released database object, if any were waiting 
for access to it. 

Once a process has been granted shared access to a specific 
database object, subsequent requests by that process for exclu- 
sive access to that database object are rejected. This restric- 
tion prevents a process from getting blocked waiting for a 
database object that it already has access to, and implies that a 
process must declare its most restrictive use when it requests 
access to the database object. (It must request exclusive access 
if there is any chance that the process might change the content 
of the database object.) In order to ensure that a process has a 
consistent view of the database, and that processes may be rolled 
back to a previous state (when necessary), no database objects 
will be released by a process until that process has reached a 
"commitment point", at which time all the database objects that 
the process had access to are released. A commitment point is 
always reached at process termination. (When a process continues 
processing after reaching a commitment point, for purposes of 
detecting deadlock, a PMM can treat it as a new process because 
it released all its database resources, and notified all pro- 
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cesses to which it could send messages that no more messages are 
forthcoming. The external effects of a process, including 
database updates and message text sent, can not be cancelled 
after commitment. Process commitment points are synchronized, 
which is to say that after a process reaches a commitment point, 
it does no further processing until all processes with which it 
has established connections over which it can receive messages 
have also reached commitment points.) 

If a process attempts to receive message text over a speci- 
fic connection, it will be given one message if any are queued 
for receipt at that process' es end of the connection. If no 
messages are available, the process is blocked until message text 
arrives. Upon arrival of a message, the process will be 
awakened, because the receiving process is uniquely identified by 
the connection over which message text is sent. Steps must be 
taken to ensure that the receiving process and the sending pro- 
cess of a message treat the same text as one message. (One pro- 
cess can't treat a line as a message when the other process 
treats a group of sentences as a message.) 

IV. 3 Creation and Expansion of an OBPL 

When a PMM wants to check whether a given blocked process is 
involved in a deadlock, it creates an 08PL and Inserts the net- 
work unique name of the process as the first process entry in the 
OBPL. (It is assumed that operators, processes and resources 
have unique names within a node, and these names can be made 
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unique within a network by qualifying them with the name of the 
node in which they reside. Throughout this Thesis, operator, 
nrocess and resource names are assumed to be network unique.) 
Call this process P1. Let R1 be the resource to which P1 desires 
access. R1 is then inserted into the resource identification 
portion of the OBPL. A PMM (which PMM depends upon what scheme 
is being used to detect deadlock, and whether PI and R1 are in 
the same node) then determines what process controls R1. If R1 
is a database object, then the process that controls R1 is the 
process that has access to it. (If there are several shared 
readers of R1, then it is said that each reader controls Rl and 
the OBPL is copied enough times so that there is one list for 
each reader of Rl, and a different copy of the OBPL is used for 
each reader.) If R1 is message text in a message group, then the 
process that controls R1 is the process that can send the desired 
message, and if R1 is message text from an operator connection, 
the process that controls the resource is the human operator that 
can send the message. If Rl is message text over a connection to 
which no process other than P1 has associated itself, the PMM 
saves the OBPL so that after another process or operator associ- 
ates itself with the connection the needed information will be 
available and the OBPL can be expanded further. It is assumed 
that no deadlock can exist unless two processes are associated 
with the connection over which the desired message text can be 
received. 

Let PK be the process that controls Rl. A PMM then checks 
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if PK already has an entry in the OBPL that is being examined. 
If it doesn't, the PMM adds its name to the OBPL and then lets 
some PMM determine if PK is active. If PK had an entry in the 
OBPL, the PMM has detected a deadlock, and should take the ap- 
propriate action. Note that the entry for PK can be anywhere in 
the OBPL, as it is possible that a process not involved in the 
deadlock may be waiting to access a resource controlled by a 
process that is involved in the deadlock. If PK is active, then 
there is no deadlock and the OBPL can be discarded. If PK is 
blocked, then the above procedure should be repeated, except PK 
should be used instead of P1 and a PMM determines what resource 
PK is waiting for. If PK represents an operator, then the PMM 
must save the OBPL until information about the status of the op- 
erator becomes available. A message is sent to the operator 
stating that this state information is desired. If the operator 
sends message text to a process, or if the operator responds that 
he/she is active, then all OBPL's that needed state information 
about this operator are discarded since there is currently no 
deadlock. If the operator states that he/she is waiting, then 
the operator connection over which the operator is awaiting a 
message must also be stated. The process that can send the op- 
erator the desired message is determined from the connection 
name, thus the PMM now knows what process controls the resource 
the operator desires, and this information is used to further 
expand all the OBPL's that needed state information about the 
operator. If no OBPL's needed this information, and the operator 
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volunteers the information that he/she is blocked, then an OBPL 
is created with the first process entry representing the opera- 
tor. 

In order to ensure that a PMM sees a consistent set of state 
tables, no resources get allocated or released in the node of the 
PMM while the PMM is examining an OBPL. (The PMM holds exclusive 
use of the state tables in its node. The reason for this re- 
striction becomes apparent in Chapter VI in the verification of 
the decentralized algorithm.) There is no chance of a PMM itself 
being involved in a deadlock because it is the only process that 
has access to the state tables in its node, and it does not wait 
for any messages or request access to any other database objects. 
Resource requests and OBPL's arriving from other nodes result in 
subroutine calls to the PMM. These calls are handled in a FIFO 
sequence. In addition, when a process or operator associates 
itself with a connection, a PMM is called to check if any OBPL's 
have been saved waiting for this information. Furthermore, when 
an operator sends message text to a process or states that he/she 
is active or blocked, the PMM at that node checks if any OBPL's 
have been saved waiting for state information about the operator 
and takes the appropriate action. 

The time at which an OBPL gets created depends upon the 
optimization of the deadlock detection scheme, and which PMM 
creates the OBPL depends upon what scheme 

(centralized/decentralized) is used. An OBPL can be created as 
soon as a process becomes blocked, or it can get created after 
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'X' units of time have elapsed without the process gaining access 
to the desired resource. The latter approach will be used with 
the expectation that normally the process will be granted access 
to the desired resource within 'X' units of time because deadlock 
does not exist. Thus the overhead involved in creating and 
expanding an OBPL will usually be avoided. However, within the 
body of this paper, in the interest of clarity it is assumed that 
an OBPL is created immediately after it is determined that a de- 
sired resource is currently unavailable. It should be understood 
that the removal of this assumption, and the imposition of a 
delay before the OBPL gets created, does not impair the 
effectiveness of the algorithms because once a deadlock occurs, 
it exists until some type of recovery action is initiated. 

Certain information must be available to the PMM's if the 
OBPL»s are to be properly expanded. The PMM at each node will 
maintain a table which has an entry for each process in its node. 
Associated with each process entry will be a list of all the 
resources to which the process currently has access, and the name 
of the resource to which the process desires access (if the pro- 
cess is waiting). For each resource at the node, the PMM must 
keep information stating what process or processes currently have 
access to that resource, and what type of access they have. In 
addition, a list of all processes that are waiting for access to 
that resource must be maintained. (The latter information is 
necessary so that the resources will be properly allocated when 
they become available.) 
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V. Centralized Approach to Deadlock Detection 
A "centralized" approach to deadlock detection in a computer 
network is based upon the premise that one node (the "control" 
node) in the network will act as the center of activity for glo- 
bal resource allocation and deadlock detection. In order to re- 
duce overhead, any requests for resources or checks for deadlock 
that can be handled entirely by one node should not request the 
service of the control node. For reasons that will be explained 
later, the following description has not been refined, and should 
not be viewed as a working algorithm. The description presents 
some ideas that could form the basis for a practical centralized 
approach to deadlock detection. 

V.I Allocation of Resources 

A process management module CPMM) will have responsibility 
for granting access to a local resource as long as no remote 
processes have been allocated the resource nor have been queued 
for it. When these conditions do not hold, the control process 
management module (CPMM) (located in the control node) will have 
responsibility for granting access to the resource. Thus when a 
process desires a remote resource, the request must go to the 
CPMM. When a process requests a local resource, the request must 
go through the CPMM only if that module currently has responsi- 
bility for granting access to the resource, otherwise the request 
will be handled by the local PMM. The set of resources for which 
the CPMM grants access changes dynamically. (As soon as a pro- 
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cess requests a remote resource, that resource becomes a member 
of the centrally managed set if it isn't already a member, and 
when the conditions above are satisfied again, the resource is 
removed from the set.) For each resource in the set, the CPMM 
maintains a list (in the global resource control table) of all 
processes queued for that resource plus the name of the process 
or processes (in the case of shared access) that have been al- 
located the resource. 

There are essentially three classes of resource requests in 
this type of network. The following is a list of the resource 
request classes and the proper response to each type of request: 

1. A process requests a resource at the same node as the 
process, and the local PMM is responsible for granting 
access rights to the resource: The PMM can block the 
process or give it the resource. In either case, the 
PMM can update the appropriate tables. 

2. A process requests a resource at the same node, and the 
CPMM has been given responsibility for granting access 
rights to the resource: A message containing the 
resource request must be sent from the local PMM to the 
CPMM. The local PMM will block the process until it 
receives notification from the CPMM that the desired 
access has been granted. Upon receipt of the resource 
request, the CPMM will either grant the process access 
to the desired resource, or keep it blocked. In either 
case, the CPMM updates its tables to reflect the state 
after this request has been processed. 

3. A process requests a resource at another node: A mes- 
sage containing the resource request must be sent from 
the local PMM to the CPMM. The local PMM will block the 
process until it receives notification from the CPMM 
that the desired access has been granted. Upon receipt 
of the resource request, the CPMM, if it had the re- 
sponsibility for granting access to the specified 
resource, will either grant the process access to the 
desired resource or keep it blocked. If the CPMM did 
not have such responsibility, it will demand it from the 
PMM that does, and then the CPMM will process the 
request. After the request has been processed, the CPMM 
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will update its tables appropriately. 
When a process reaches a commitment point, the local PMM 
will release all the resources that the process controlled. The 
PMM can then grant other local processes access to the resources 
that were released and for which it has responsibility for 
granting access. If any resources which were under the CPMM's 
control were released, the CPMM will be notified of the reaching 
of a commitment point by the process, and it will then grant 
other processes access to the resources if any are queued for 
them and the rules for resource allocation permit the new 
assignments. If possible, following a resource release, the CPMM 
will return responsibility for granting access to a resource back 
to the PMM in the node where the resource resides. 

V.2 Deadlock Detection 

When a PMM denies a request for a resource and blocks a 
process, it then creates an OBPL with a process entry for the 
blocked process. It then expands the OBPL until 1) a deadlock is 
detected, 2) it is ascertained that there is no deadlock, or 3) 
the PMM does not have enough information to expand the OBPL fur- 
ther (because an involved process is waiting for a global 
resource, or a local resource is controlled by a remote process). 
In the latter case the PMM sends the OBPL to the CPMM, which will 
complete the expansion of the OBPL. When the CPMM denies a 
request for access to a resource, it creates an OBPL with a pro- 
cess entry for the blocked process and then expands the OBPL un- 
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til a deadlock is detected or it is ascertained that no deadlock 
exists. 

To expand an OBPL, a PMM uses its state tables that were 
described in Chapter IV, and the CPMM uses its global resource 
tables and those of the PMM's in the network. (How it obtains 
copies of these tables is discussed later in this chapter.) The 
method by which the PMM's expand an OBPL will be described first, 
and it will be followed by the method which is used by the CPMM. 
After a PMM has created an OBPL, it acts as if it were in step 2 
below, with PN set to the name of the process which was just 
blocked, and RN set to the name of the resource for which PN is 
waiting. The following is a list of steps taken by a PMM when 
expanding an OBPL: 

1. Let PN be waiting for resource RN. If RN is a local 
resource, go to step 2, otherwise go to step 6. 

2. If RN is controlled only by local processes, go to step 
3, otherwise go to step 6. 

3. Let PX be the process controlling RN. If PX is blocked, 
go to step M, otherwise there is no deadlock and the 
OBPL can be discarded. (If there are J shared readers 
of RN, repeat this step once for each reader.) 

*». If PX is already contained as a process entry in the 
OBPL, there is a deadlock and the PMM must take appro- 
priate action. If PX is not in the OBPL then go to step 
5. 

5. Append PX as a process entry in the OBPL and go to step 
1, where PX is used in place of PN. 

6. Place RN into the resource identification portion of the 
OBPL and send the OBPL to the CPMM. Halt. 

The CPMM will create an OBPL when it denies a request for 

access to a resource. The only process entry in the newly cre- 
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ated OPPL is for the process whose resource request could not 
currently be honored. After a CPMM has created an OBPL, it 
starts in step 1 below, with RN set to the resource whose 
unavailability resulted in the OBPL being created. If the CPMM 
receives an OBPL from a PMM, it sets RN to the resource that was 
placed in the resource location of the OBPL, and sets PN to the 
last process to be inserted into the OBPL. The CPMM verifies 
that PN is still waiting for RN (if it isn't, either RN has al- 
ready been allocated to PN or the CPMM has not yet received the 
request by PN for access to RN, so there is currently no deadlock 
and the OBPL can be discarded) and then starts in step 1 below. 
The following is a list of steps taken by the CPMM when expanding 
an OBPL: 

1. Let PX be the process controlling RN. (If there are J 
shared readers of RN then repeat this step once for each 
reader.) To find PX, the CPMM first checks if RN is in 
the global resource table. If it is, then this table is 
used to get PX, otherwise the copies of the local tables 
for the node in which RN resides are used by the CPMM. 
Go to step 2. 

2. If PX is blocked, go to step 3, otherwise there is no 
deadlock and the OBPL can be discarded. (First check if 
PX is waiting for a global resource, and if it isn't, 
then check the copies of the local tables for the node 
in which PX resides in order to find out if PX is 
blocked or active.) 

3. If PX is already contained as a process entry in the 
OBPL there is a deadlock and the CPMM must take appro- 
priate action. If PX is not contained in the OBPL, go 
to step 4. 

4. Append PX as a process entry in the OBPL and go to step 
5, where PX is used in place of PN. 

5. Let PN be waiting for RN. (If PN is waiting for a glo- 
bal resource, use the global resource table to determine 
RN, otherwise use the copy of the local tables for the 
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node in which PN resides.) Go to step 1. 

V.3 Issues to be Resolved 

There are several problems with the algorithm as described 
in the previous section. A major problem is determining how the 
CPMM maintains its copies of the tables belonging to the PMM's in 
the network. One possibility is to have each PMM send a copy of 
its tables to the CPMM every 'X' units of time. Another is to 
have the CPMM request a new copy of the tables that it needs if 
•Y' units of time (Y may equal 0) have elapsed since it last 
received a copy of the desired table. In either case, once a 
deadlock has been detected, all the tables of the nodes whose 
processes and resources are involved should again be requested by 
the CPMM in order to verify that the deadlock exists and that the 
CPMM's detection was not a result of the CPMM looking at an 
inconsistent state of the network. (Due to the fact that the 
list of resources that are kept in the global resource table 
changes dynamically, and the CPMM does not always have an up to 
date copy of the local tables, it is possible that some needed 
information may be incorrect and could cause problems for the 
CPMM.) It is probable that there are better and more reliable 
methods of maintaining the copies of the local tables in the 
CPMM. 

When the CPMM is expanding an OBPL, and encounters a process 
waiting for message text from an operator, it can be difficult to 
get the needed state information. A method is needed whereby the 



43 



CPMM can save the OBPL and notify the PMM at the node in which 
the operator resides, that this state information is desired. 
The PMM must then query the operator and send the CPMM this in- 
formation along with its latest state tables. 

Another problem that must be resolved occurs when related 
messages cross between two nodes. An example of this is that the 
CPMM may return the rights to grant access to a resource to a PMM 
at the same time that the PMM under discussion sends a request to 
the CPMM stating that one of its processes would like to access 
that local resource. Care must be taken when designing the 
resource allocation scheme to ensure that cases like this will be 
detected and the desired action (which in this case is granting 
the process access to the resource) will occur. In addition, 
steps must be taken in the deadlock detection algorithm to ac- 
count for and detect similar problems. 

V.4 Reasons for not Refining the Algorithm 

Several factors led to the decision not to refine the above 
algorithm to the point where it could easily be proved to work. 
It was felt that with all remote resource requests going to one 
node, there would be message congestion at that node, plus there 
would be an extra delay due to the fact that a request must go 
through the central node rather than going directly to the node 
in which the desired resource resides. Another factor that in- 
fluences message congestion is the size of the tables that will 
get sent from the PMM's to the CPMM. Since database records may 
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be considered resources, these tables can get quite large, and it 
would be preferable to only send the CPMM parts of these tables, 
but then there is the problem of deciding which parts should be 
sent, and what the CPMM should do when it was not sent enough 
information. 

When one node is used as the center of activity in a net- 
work, the network becomes only as reliable as that node. It 
would be possible to have another node in the network serve as a 
backup to the CPMM and maintain copies of the CPMM'S tables. 
There would be a delay in updating this duplicate copy, and it 
would have to be decided how often the copy should be updated. 
(A great deal of overhead is involved if a message is sent to the 
"backup" node every time the CPMM changed its tables.) It would 
also be possible to reconstruct the CPMM's tables at another node 
by requesting information from all other nodes in the network, 
thus saving the overhead involved in maintaining the duplicate 
copy at a cost of added delay if the control node were to become 
inoperable for some reason. In a computer network it is desira- 
ble to distribute the computing and to minimize the overall net- 
work problems when one node crashes. This was the major reason 
it was decided not to spend time refining an algorithm for 
deadlock detection which relies upon one node in the network. 
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VI. Decentralized Approach to Deadlock Detection 
A "decentralized" approach to deadlock detection in a com- 
puter network is based upon the premise that there should be no 
central or control node and that all nodes in the network will 
share the responsibility for detecting deadlocks. In addition, 
the failure of one node should only affect the processes of that 
node and the processes of other nodes which are accessing that 
node's resources. The amount of duplicate process and resource 
state information among the various nodes in the network will be 
kept to a minimum, and each node will be requested to help check 
for a deadlock only when at least one of its processes or 
resources is involved. 

VI. 1 Allocation of Resources 

A process management module (PMM) located at each node will 
always have responsibility for granting access to resources lo- 
cated at that node. Whenever a process requests a resource, the 
request will be processed by the PMM at the same node as the 
process. This PMM will determine if the desired resource is lo- 
cal or if it is located at a different node. (Message text 
should be treated as local to the node of the sending process.) 
If it is a local resource, then the PMM can immediately determine 
if the desired access may be granted or if the process must be 
blocked waiting for the availability of the resource. If the 
request is for a remote database object, then the PMM must block 
the process and send a remote database object request (RDOR) to 
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the PMM in the node which contains the desired resource. Upon 
receipt of an RDOR from another node, a PMM will determine if the 
requesting process must remain blocked or if it may be granted 
access to the desired resource. If access is granted, a remote 
database object assignment (RDOA) is sent to the PMM in the node 
in which the requesting process resides. Upon receipt of this 
RDOA, the PMM will awaken the proper process and notify it of the 
resource assignment. If the process must remain blocked, no 
message is sent to the node in which the process resides. The 
details of implementing this feature are not described, as they 
are not relevant to the scope of this Thesis. 

When a process reaches a commitment point, the PMM at its 
node will release all the database resources that the process had 
access to and notify the necessary processes that no more mes- 
sages are forthcoming from the specified process. All local 
resources can be immediately allocated to other processes in ac- 
cordance with the rules for resource allocation, and messages 
must be sent to all nodes which had resources allocated to the 
process, informing their PMM's of the reaching of a commitment 
point. Upon receipt of such a message, the PMM will 
appropriately update its tables and assign the resources to other 
processes in accordance with the rules for resource allocation. 

VI. 2 Deadlock Detection 

When a PMM determines that a resource at its node can not 
currently be allocated to a process that requested it, the PMM 
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creates an OBPL (ordered blocked process list) with a process 
entry for the blocked process. It then expands the OBPL until 1) 
a deadlock is detected, ?) it is ascertained that there is no 
deadlock, or 3) the PMM does not have enough information to fur- 
ther expand the OBPL. (Note that if a database object has been 
requested, the OBPL is created in the node where the database 
object resides, whereas if message text has been requested, the 
OBPL is created in the node where the requesting process 
resides.) The PMM starts expanding the newly created OBPL in 
step 10 below. When a PMM receives an OBPL from another node, it 
starts in step 1 below in an attempt to complete the expansion of 
the OBPL. The reasoning behind each step is contained in the 
next section, and these explanations should be read before one 
attempts to verify the correctness of the algorithm. It should 
be noted that within the algorithm, PX and RX are names of vari- 
ables whose contents represent processes and resources, respec- 
tively, even though they are sometimes used as though they were 
process and resource names themselves. 

1. Set RX to the value contained in the resource 

identification portion of the OBPL. If RX represents a 
resource which is local to the node expanding the OBPL, 
then go to step 2, otherwise go to step 8. 

?. Verify that the last process added to the OBPL is still 
waiting for RX. If it isn't then discard the OBPL and 
halt, otherwise go to step 3. 

3. Let PX be the process controlling RX. (If there are J 
shared readers of RX, then repeat this step once for 
each reader.) If PX already has a process entry in the 
OBPL, then there is a deadlock and the PMM must take the 
appropriate action. If PX is not in the OBPL then go to 
step *J. 
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4. If PX represents a process which is local to the node 
expanding the OBPL, then go to step 5, otherwise go to 
step 7. 

5. If PX is active, there is no deadlock, so discard the 
OBPL and halt. Otherwise go to step 6. 

6. Append PX as a process entry in the OBPL and go to step 
10. 

7. Append PX as a process entry in the OBPL. Place RX into 
the resource identification portion of the OBPL and send 
the OBPL to the PMM in the node in which PX resides. 
Halt. 

8. Verify that the last process added to the OBPL still has 
access to RX. If it doesn't, discard the OBPL and halt. 
Otherwise go to step 9. 

9. If the last process added to the OBPL is active, there 
is no deadlock, so discard the OBPL and halt. Otherwise 
go to step 10. 

10. Get the name of the resource for which the last process 
added to the OBPL is waiting and call it RX. If RX 
represents a resource which is local to the node 
expanding the OBPL, go to step 3, otherwise go to step 
11. 

11. Place RX into the resource identification portion of the 
OBPL and send the OBPL to the PMM in the node in which 
RX resides. Halt. 



VI. 3 Explanation of Steps in the Deadlock Detection Algorithm 

The following is a description of the reasons for including 

each step in the deadlock detection algorithm described in the 

previous section. Each numbered paragraph below corresponds to 

the step with the same number in the previous section. 

1. An OBPL will be sent to a node when it must be deter- 
mined what process controls a given resource, or what 
state (active or blocked) a given process is in. If the 
resource that was named in the resource identification 
portion of the OBPL is local to the node that just 
received the OBPL, then in order to expand the OBPL the 
PMM needs to know what process has access to that 
resource and it goes to step 2, otherwise it goes to 
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step 8 in order to check the state of the last process 
to be added to the OBPL. 

It must be verified that the last process added to the 
OBPL is still waiting for RX because it is possible that 
while the OBPL was sent from the PMM in the node con- 
taining the process, the PMM in the node containing RX 
sent a message stating that the process has been granted 
access to RX. If this process is no longer waiting for 
RX, the state that was assumed when the OBPL was sent no 
longer exists, and the OBPL can be discarded. 

If RX represents a database object, then the last pro- 
cess added to the OBPL is still waiting for RX if it is 
still queued for access to the database object. If RX 
represents a message in a message group, then RX is 
qualified by the sequence number of the message within 
the message group that is desired. (If the process has 
already received N messages over the specified connec- 
tion, then it is waiting for message number N+1 in the 
message group.) The process is still waiting for the 
specified message only if the number of messages already 
sent to it over the given connection is less than the 
number that qualified the message group r>ame. 

If PX already has a process entry in the OBPL, then 
there is a loop of processes each waiting for a resource 
that is controlled by the next process in the loop, so a 
deadlock has been detected. If PX does not have a pro- 
cess entry in the OBPL, go to step 4 in order to expand 
the OBPL further if PX is not active. 

If RX is a database object which has J shared readers, 
then a copy of the OBPL must be made for each of these 
readers because the process that requested access to RX 
will not be able to access RX if the process is in a 
deadly embrace loop involving any one of the J readers. 

If PX is local to the node which is expanding the OBPL, 
then the PMM can immediately check the state of PX, so 
it goes to step 5. If PX is not a local process, the 
OBPL must be sent to the node in which PX resides, so 
the PMM goes to step 7. 

If PX is not currently blocked waiting for access to any 
resources, there can be no deadlock currently involving 
PX. If PX represents an operator, the OBPL must be 
queued waiting for state information about the operator. 
The PMM will then ask the operator to enter information 
about his/her state. The acceptable operator responses 
are 1) that he/she is waiting for a message over a given 
operator connection, 2) that he/she is active, or 3) a 

50 



.,**! : «*<*, .'<g«jS^^*w^iJ(J|^i*rtS(«^J»«Ki- 



regular message over an operator connection. If the 
operator sends a regular message, or states that he/she 
is active, then there is no deadlock and all the OBPL's 
that are queued for state lnformat ion about this opera- 
tor will be discarded. If the operator states that 
he/she is waiting for a wes#*ge, thf#« the PMM can (by 
the use of the given operator connection) determine what 
process can send the message .t*^•4*• ! *tl•''''5df|^e^#€trt i ■ desires, 
and the PMM can then fur t«#r expand th* OBPL. It may be 
desirable to "time out" a noWre sp^siVe operator, as 
operator inaction can stall the sy*t£etir and perpetuate an 
undetected deadlock. 

6. PX is blocked, so insert it as the last entry in the 
OBPL and then go to step 10 in order to further expand 
the OBPL. 

7. Insert PX as the last entry in the OBPL even though the 
PMM does not know the state (active or blocked) of PX. 
(This will be checked by the node that will receive the 
OBPL.) Place RX into the resource identification 
portion of the OBPL to indicate that PX currently con- 
trols RX, and the state of Ptf is needed Information. If 
PX represents a message within a message group, it is 
qualified by the sequence number olf-'tb* message within 
the message group that is desired. The PMM therefore 
sends the OBPL for further expansion to the PMM in the 
node which contains PX. 

8. It must be verified that the last process added to the 
OBPL still has access to RX because it Is possible that 
while the OBPL was sent from the' PMM in thfr node con- 
taining RX, the PMM in the node containing the process 
sent a message stating that RX has been released by the 
process. If the process no longer has access to RX then 
the state that was assumed when tne OBPL was sent no 
longer exists, and the OBPL can be discarded. 

9. If the last process added to the OBPL is not currently 
blocked waiting for access to any resources, there can 
be no deadlock currently involving the process. If the 
process is blocked, the PMM goes to step 10 because the 
process already has been inserted as the last process 
entry in the OBPL. 

10. Step 10 can be reached from step 6 or step 9. In either 
case, the last process added to the OBPL is local to the 
node which is expanding the OBPL, so the PMM can find 
out what resource the process desires access to. Set RX 
to the name of this resource. If RX is local to the 
node that is currently expanding the OBPL, the PMM can 
continue to expand the OBPL, so it goes to step 3, 
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otherwise it goes to step 11. 

11. To further expand the OBPL, what process has access to 
RX must be known, so the PMM sends the OBPL to the PMM 
in the node in which RX resides. Place RX into the 
resource identification portion of the OBPL to indicate 
that the last process added to the OBPL is blocked 
waiting for access to RX and what process controls RX is 
needed information. In the case where RX represents a 
message within a message group, it is qualified by the 
sequence number of the message within the message group 
that is desired. Send the OBPL for further expansion to 
the node in which RX resides. 



VI. H Verification of the Algorithm 

There are two parts in the verification of the correctness 
of the decentralized algorithm for deadlock detection. The first 
and most important part is to prove that all deadlocks get 
detected. The second part is proving that a deadlock is not 
"detected" when (except in a special case discussed later) one 
does not exist. 

Part 1 

To prove that all deadlocks get detected, it will be 
shown that once a deadlock state is reached, an OBPL will be 
created that will be passed among nodes which will expand it 
until the deadlock is detected. There are two assumptions 
that are required for this proof: 1) All internodal mes- 
sages eventually get received by the proper nodes (and 
therefore no OBPL's are "lost" in the transmission between 
nodes), and 2) while the OBPL is being expanded, none of the 
processes involved in the deadlock are aborted (which would 
break the deadlock before it is detected) or rolled back to 
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a previous state (which would imply the deadlock has been 
detected by the expansion of another OBPL) . 

Let a deadlock consist of processes P1, P2, ..., PN, 
with PI waiting for a resource controlled by P2, ..., and PN 
waiting for a resource controlled by P1. (Process names are 
unique within a node and they can be made network unique by 
qualifying them with their node names, so throughout this 
proof, assume the Pi represent distinct processes.) When 
each process, Pi, involved in the deadlock was denied access 
to a resource controlled by another process in the deadlock, 
an OBPL was created with the first process entry represent- 
ing Pi. One of these OBPL's must have been the last (in 
time) to be created, thus the deadlock existed at that time. 
(If two or more of these OBPL's were created simultaneously 
and they were the last to be created for processes involved 
in the deadlock, then any one in this "last group" may be 
arbitrarily selected as the last to be created. The 
important point is that the deadlock existed at the time the 
OBPL was created, and all the relevant tables collectively 
contain the information showing each process in the deadlock 
waiting for a resource controlled by another process in the 
deadlock.) For simplicity, assume that this last OBPL con- 
tains P1 as its first process entry. Additionally, in the 
ensuing discussion, a message from an operator to a 
computerized process will not be treated as a special type 
of resource because it is assumed that operators will state 
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what they are waiting for when asked to do so by a PMM. 

After P1 has been inserted as the first process entry 
in this "last" OBPL, the PMM which will begin the expansion 
of the OBPL will be in step 10 of the algorithm. If P1 is 
waiting for access to a resource local to a different node, 
then the PMM executes steps 10 and 11, and another PMM 
(after receipt of the OBPL) executes steps 1 and 2, then 
goes to step 3, otherwise the PMM executes step 10 and goes 
to step 3. (Since there is a deadlock, the OBPL will not be 
discarded.) Now, no matter what P1 is waiting for, it can 
be assumed that a PMM is about to start step 3 and it can 
(i.e. it has the information in its tables) determine what 
process (in this case, P2) controls the resource P1 has re- 
quested. There are two ways (depending on whether P2 is 
local or global to the node in which the OBPL is currently 
located) in which a process entry for P2 will be inserted 
into the OBPL. 

Case A: P2 is "local". 

Steps 4, 5 and 6 are executed, then step 10 will be 
executed. The PMM will then be ready to execute step 3 
or it will execute step 11 and another PMM will execute 
steps 1 and 2, and will be prepared to execute step 3- 

Case B: P2 is "global". 

Steps 4 and 7 are executed, then the PMM which then 
receives the OBPL will execute steps 1, 8, 9 and 10. 
It will then be ready to execute step 3 or it will ex- 
ecute step 11 and another PMM will execute steps 1 and 
2, and will be prepared to execute step 3. 

This "last" OBPL now has process entries for P1 and P2, 

and a PMM is about to execute step 3 to continue the 
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expansion of the OBPL. A PMM is now essentially in the same 
position some PMM was in shortly after the OBPL was created. 
The only difference is that now two processes have entries 
in the OBPL, and RX is set to the resource for which ?2 is 
waiting, rather than the resource for which P1 is waiting. 
By repeating the above procedure as many times as necessary, 
the OBPL will be expanded to include process entries for 
processes P1, P2, ..., PN. At this point, when step 3 is 
executed, it will be determined that P1 controls the 
resource PN has requested, and the deadlock will be 
detected. 

OED Part 1. 

Part 2 

To prove that every deadlock that gets "detected" ac- 
tually is a deadlock, it must be shown that an OBPL will be 
discarded whenever there is a change in the state that was 
assumed when a process entry was made in that OBPL. (The 
one exception, which is ignored in the ensuing discussion, 
is the case where the assumed state changes due to the 
aborting or rolling back of a process, rather than having 
the state change due to a waiting process being awakened and 
granted access to the resource for which it was waiting.) 
This condition is sufficient because if a deadlock is 
"detected" when expanding the OBPL containing (in order of 
insertion) process entries for P1, P2, ..., PM, PN, and 
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there has been no change in the state that was assumed when 
each process was entered into the OBPL, then P1 is still 
waiting to access a resource controlled by P2, ..., PM is 
still waiting to access a resource controlled by PN, and PN 
is still waiting to access a resource controlled by PJ, 
where PJ appears earlier in the OBPL. Thus a deadlock ac- 
tually exists if one is "detected" and there has been no 
change in the state that was assumed when the process en- 
tries were inserted into the OBPL. 

Assume that a PMM is expanding an OBPL with process 
entries (in order of insertion) PI, P2, ..., PK, PL. If the 
algorithm is correct, then P1 is waiting for access to a 
resource controlled by P2, ..., and PK waiting for access to 
a resource controlled by PL. Now assume that this state 
does not hold. That is to say, for some Pi, Pj with adjac- 
ent process entries in the OBPL, either Pi is not waiting 
for access to the same resource (say RQ) for which it was 
waiting when it was ascertained that Pi was blocked and that 
Pi should have an entry in the OBPL, or Pj no longer con- 
trols RQ. It will be shown that whenever this situation 
occurs, it will be detected and the OBPL will be discarded. 

It can be assumed that Pi and Pj are PK and PL respec- 
tively, because if the state has changed from what was as- 
sumed when Pi was inserted into the OBPL, then it either 
changed before a PMM checked to see what Pj was waiting for, 
Pj was not blocked, or the state changed after there was a 
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similar state change involving Pj and the next process in 

the list. (The latter claim can be made because if Pi was 

waiting for access to RQ which was controlled by Pj, and Pj 

controlled RQ and was blocked at the time that it was 

decided to further expand the OBPL, the only way the assumed 

state could change would be for Pj to incur a state change 

and be awakened so that it could release RQ.) 

In order to show that PK is still waiting for RQ, and 

that RQ is still controlled by PL whenever it is decided 

that another process should be added to the OBPL, two cases 

must be considered. 1) PL, PK and RQ are all located in the 

same node, and 2) PL, PK and RQ are located in two or three 

different nodes in the network. 

Case 1. 

Due to the restriction that operators can only 

communicate with processes, there are three possible 

combinations of the types (process or operator) of PL 

and PK. (The resource type of RQ is either unimportant 

or uniquely determined by PK and PL.) 

Case A: PK and PL are both processes. 

Once PK has been inserted into the OBPL, and the 
PMM in the node in which PK resides is expanding 
the OBPL, the PMM determines that PK is waiting 
for access to RQ and that PL controls RQ. It then 
inserts PL into the OBPL if PL is blocked and 
discards the OBPL if PL is active. Since the PMM 
has exclusive use of the state tables in its node, 
there is no way the assumed state will change un- 
til after the OBPL is discarded, sent to another 
node or queued waiting for state information about 
an operator (in which case the state can not 
change until after the operator states that he/she 
is active or sends a message to a process, both of 
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which result in the OBPL being discarded). 

Case B: PK is an operator and PL is a process. 

PK is not inserted into the OBPL until the opera- 
tor states that he/she is waiting for a message 
over a given operator connection (RQ). The PMM in 
the node in which PK resides then determines that 
PL is the process that can send the desired mes- 
sage. If PL is blocked, it is inserted into the 
OBPL, otherwise the OBPL is discarded. Since the 
PMM has exclusive control of the state tables in 
its node, the assumed state can not change until 
after the OBPL is discarded, sent to another node, 
or queued waiting for state information about an 
operator. 

Case Cr PK is a process and PL is an operator. 

PL is not inserted into the OBPL until the opera- 
tor states that he/she is waiting for a message 
over a given operator connection. PK is still 
waiting for a message from PL because the OBPL 
would have been discarded if any message text had 
been received from the operator since the OBPL was 
queued waiting for state information about the 
operator. (Note that it is possible that the de- 
sired message may have been sent by the operator 
before the OBPL was queued, but it has not been 
given to PK because calls to the PMM are processed 
in a first in, first out fashion. In this case 
though, the OBPL will be discarded before any 
state message from the operator is processed, be- 
cause the desired message text was sent before the 
operator state message.) The OBPL will then ei- 
ther be discarded or have another process entry 
added to it, because an operator can only wait for 
a message from a process located at the same node. 

Case 2. 

Whenever an OBPL is sent between nodes, it must be 

verified that the state that was assumed when the OBPL 

was sent is still valid. Operators do not cause any 

OBPL's to be sent between nodes (because they only 

communicate with processes at their own nodes), thus in 

this discussion PK and PL are always processes. There 



58 



are four combinations of the resource type of RO and 

the locations of PK, PL and RQ. 

Case A: RQ is a database object located in the same 
node as PK, but different from PL. 
After it is ascertained that PK is blocked waiting 
for access to RO, it is determined that PL con- 
trols RQ. PL is then inserted into the OBPL 
(after the entry for PK) and the OBPL is sent to 
the PMM in the node in which PL resides. When the 
PMM receives the OBPL, it first verifies that PL 
still controls RQ. If it doesn't, there has been 
a change in the assumed state (PL has released 
RQ), and the OBPL is discarded. Note that the 
OBPL is also discarded if it is determined that PL 
is not blocked. 

Case B: RQ is a database object located in the same 
node as PL, but different from PK. 
After it is ascertained that PK is blocked waiting 
for access to RQ, the OBPL is sent to the PMM in 
the node in which RQ and PL reside. Upon receipt 
of the OBPL, this PMM verifies that PK is still 
waiting for access to RQ. If it isn't, there has 
been a state change (PK was granted access to RQ) , 
and the OBPL is discarded. The OBPL is also 
discarded if it is determined that PL (which con- 
trols RQ) is not blocked. 

Case C: RQ is a database object located in a node 
which contains neither PK nor PL. 

After it is ascertained that PK is blocked waiting 
for access to RQ, the OBPL is sent to the PMM in 
the node in which RQ resides. Upon receipt of the 
OBPL, this PMM verifies that PK is still waiting 
for access to RQ. If it isn't, there has been a 
state change, and the OBPL is discarded. If PK is 
still waiting for access to RQ, then the PMM in- 
serts PL into the OBPL (since PL controls RQ) and 
sends the OBPL to the PMM in the node in which PL 
resides. After the OBPL is received, the PMM then 
checks that PL still controls RQ. If it doesn't, 
there has been a change in the assumed state, and 
the OBPL is discarded. The OBPL is also discarded 
if it is determined that PL is not blocked. 

Case D: RQ represents message text and PK and PL are 
located in different nodes. 

After PK is inserted into the OBPL because the 
process is waiting for message text in message 
group RQ, RQ is qualified by a message number. 
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The OBPL is then sent to the node in which PL 
resides. PL will only be inserted into the OBPL 
if it is blocked and the specified message has not 
been sent (which implies PK is still in the state 
it was in when it was inserted into the OBPL), 
otherwise the OBPL will be discarded. 

It has been shown that whenever the relevant portions 
of the overall network state differ from the state that was 
assumed when process entries were inserted into the OBPL, 
the situation is detected and the OBPL is discarded. 
Therefore it is impossible to detect anything but deadlocks 
since a deadlock is never "detected" unless a PMM wants to 
insert a process into an OBPL when there is already a pro- 
cess entry in the OBPL for that process. It has thus been 
proven that the decentralized algorithm only "detects" 
deadlocks. 

OED Part 2. 
QET) Decentralized Algorithm. 

VI. 5 Some Properties of the Algorithm 

It should be noted that all references to processes in the 
previous sections actually referred to process "commitment units" 
(the period between commitment points), and the fact that 
commitment units within a process are network unique allows a 
deadlock to be detected at a node different from the one which 
contains the process that was found to already have a process 
entry in an OBPL. This situation can arise if the process under 
discussion controls a remote database object, and the PMM at the 
node in which the database object resides wants to insert the 
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process into the OBPL due to its controlling the above mentioned 
database object. The OBPL need not be sent to the PMM in the 
node in which the process resides to verify that the process 
still controls the database object, because the process has not 
reached a commitment point (by virtue of the fact it already has 
an entry in the OBPL) and therefore has not released any database 
objects . 

All resource requests will be handled with minimal delay 
because, for any request, the only nodes involved are those which 
contain the associated process and resource. (No information is 
needed from any other nodes to process the request.) The algo- 
rithm will function properly regardless of the resource 
allocation scheme in use, since the needed information about a 
resource is what process (or processes) currently controls it, 
not the order in which processes will be granted access to the 
resource in the future. (The latter information is necessary 
only for deadlock avoidance algorithms.) 

While a PMM is expanding an OBPL, all other PMM's may be 
processing resource requests and releases. A PMM need only see a 
consistent state within its own node in order to expand an OBPL. 
The restriction that a PMM can not process resource requests and 
releases while it is expanding an OBPL can be removed if the 
decentralized algorithm is modified slightly. In step 10 the 
branch to step 3 would be eliminated (and therefore always go to 
step 11 after step 10), and then in step 11 a PMM may send an 
OBPL to itself. The new restriction would be that no resource 
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requests or releases can be processed while a PMM is executing 
steps 1 through 11, although resource requests and releases could 
he processed between the execution of step 11 and step 1. 

The same deadlock can be detected more than once if pro- 
cesses and resources located in two or more nodes are involved. 
This situation will occur if two or more processes request 
request resources at approximately the same time, resulting in 
ORPL's being created starting with different processes in the 
same deadlock loop. It is important to note that no matter how 
long it takes for OBPL's, remote resource requests, remote 
resource assignments, message text in message groups, and noti- 
fication of a remote process termination to travel between nodes, 
the algorithm still functions as expected due to the verification 
steps that are included and the fact that once a deadlock exists, 
it will not be broken until after it is detected and recovery 
action is initiated. 
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VII. ADT Model of the Decentralized Algorithm 
A functional model of the decentralized algorithm described 
in the previous chapter was designed and created using the 
facilities of the Architectural Definition Technique (ADT). The 
model was designed so that the algorithm could be easily tested. 
Additionally, by designing the model at the same time that the 
algorithm was being refined, several deficiencies of early ver- 
sions of the algorithm were detected and corrected. (See section 
VII. 2 and [1] for information about ADT.) 

The model was written in PL/I and runs on the Honeywell 
Multics timesharing system. It was coded for ease of use and 
readability, and is not intended to suggest the most efficient 
way of implementing the algorithm in a computer network. A pre- 
requisite to the use of ADT is an ability to understand the con- 
cept behind Data Structure Diagrams. 

VII. 1 Data Structure Diagrams 

An information structure can be described by a Data Struc- 
ture Diagram. A particular object in an information structure is 
referred to as an "entity", and an entire group of similar enti- 
ties is called an "entity-class". (They are characterized by a 
prototype called an "entity-type".) The grouping that associates 
one or more entities of the same entity-class with one entity of 
a second entity-class (same or different type) in a subordinate 
relationship is known as an "entity-set". In a Data Structure 
Diagram, a block is used to represent an entity-type (the 
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entity-type name is written inside the block). A "set-class" is 
a collection of similar entity-sets. (They are characterized by 
a prototype called a "set-type".) An arrow represents a 
set- type. It designates (by pointing from) the entity-type that 
"owns" the set-type and designates {by pointing to) the 
entity-type that serves as the "member*" of the set. 

There is a 1 to n relationship between the owner and members 
of an entity-set: n may be zero, one or more. For each owner 
there may be any number of members, but for each member, there is 
only one owner in any set occurrence. A dashed arrow is used to 
represent a set-typ* where the member relationship may or may not 
exist. This is called a "sometime* member relationship. When 
there can be only one member in an entity-set, a line (rather 
than arrow) is drawn between the owner entity-class and member 
entity-class. A dashed line is used when there can be a sometime 
one-to-one relationship. 

A situation ean arise where a s«t-ty|xe can have more than 
one type of entity in the member role. In this «ase a multihead 
arrow is used to represent the set»tyf»e. Similarly, a multitail 
arrow is used to represent a set-typ* where more than one type of 
entity can assume the owner role (although each member has only 
one owner), A more detailed explanation of Data Structure 
Diagrams ean be found in [2]. 

VII.? Architectural Definition Technique 

ADT is an approach to arriving at a complete, concise, 
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non-ambiguous functional specification of a software or hardware 
system which is totally independent of packaging considerations. 
To use APT, one must describe the system state variables in terms 
of occurrences of entity-types, attribute types and set-types, 
and create a user interface as a set of machine processable 
function definition algorithms. 

An example of an entity-type is "node" in a computer net- 
work. Each node in the network must have a name, which is an 
attribute of the entity. The entity-type and its attributes must 
be declared. In addition, all entity-sets which a node may 
belong to as a member or owner must be declared, and the rela- 
tionship ("member", "owner", or "recursive") must be stated. A 
node is a member of the set of all nodes in a network, but it is 
the owner of various resources and processes located at that 
node. The manner in which entities and their attributes and set 
relationships are represented in the machine is irrelevant to the 
goal of achieving a functional specification. Therefore the ADT 
user is relieved of this burden. 

A function definition algorithm is a body of code which 
specifies what action should take place in response to a given 
external stimulus. A function definition algorithm has several 
responsibilities. 1) It must validate the input parameters, 2) 
It must execute the logic of the function, 3) It must access the 
system state tables and update them appropriately to reflect the 
action taken, and 4) It must provide an external response repre- 
senting the action (or lack thereof) that has taken place. A 
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function definition algorithm usually includes a series of calls 
to the ADT modelling subroutines. 

One integral part of ADT is a set of procedures which faci- 
litate the modelling of the "system state". These procedures 
provide the capability to create and maintain a network 
structured database which holds the entities, attributes and re- 
lationships used to model the system. 

A functional model created using ADT can be exercised and 
"validated" by the creation and execution of a sequence of 
commands. (Calls to the various function definition algorithms.) 
Any number of commands can be executed so that the model can be 
ohserved in order to determine if it acts in accordance with 
expectations. 

Facilities are furnished in ADT to save these sequences of 
commands (scenarios) and to automatically execute them. There 
are also facilities so that the system state can be saved and 
restored. Display facilities are provided which permit a de- 
tailed examination of the system state without altering it. 
Using these facilities it is easy to construct experiments, alter 
them and examine the results at any time. 

ADT is a deterministic system, and the machine is always in 
a stable state during the period between calls to the various 
function definition algorithms. 

VII.? The Deadlock Detection Model 

The deadlock detection model which runs using ADT was de- 
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signed to be driven entirely by the user of the model. All the 
nodes in the network must be created by the model user, as are 
processes and database resources located at each node. In addi- 
tion all operators at each node must be declared. Each node in 
the network must have a unique name. Operator names and process 
names appear together in the same name space and must be unique 
within each node. They are qualified by the node name to make 
them unique in the network. Database objects must also have 
unique names within the set of database objects at a node. 

Process wait situations may arise as a result of requests 
for message text in a message group or over an operator connec- 
tion, or requests for access to a database object, but operator 
wait situations are not forced by the system because operators do 
not request message text, they only take it as it comes over an 
operator connection. All requests by processes for resources 
must be entered by the model user. The model will process the 
requests, and allocate the desired resources, if possible, 
otherwise the requesting process will be blocked. When message 
text is requested, the message group name (in the case of process 
to process communication) or operator connection name (for oper- 
ator to process communication) must be given. With the model, 
before message text in a message group can be received by a 
process, the message group must first be initiated by the process 
which can send the messages, and then be accepted by the process 
that will receive the messages in the message group. (The model 
user specifies when this takes place.) Actual systems may allow 
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message groups to be accepted by a process before another process 
initiates it. An operator connection must be established (by the 
model user) between an operator and a process at the same node 
before a process can receive message text over the operator con- 
nection. This model does not support the sending of messages 
from a process to an operator over an operator connection because 
typically messages from a process to an operator are not queued 
for receipt by an operator, they are simply printed at the 
operator's terminal without an explicit operator request. 

In order to make the model easier to use, it was decided to 
make message group names and operator connection names unique 
within the network. 

In a computer network it is probable that message text may 
be sent by either process involved in a connection through which 
they are communicating. (This is a two-way connection.) The 
model only allows the initiator of a message group to send mes- 
sage text over the associated connection because a two-way con- 
nection can be simulated using two one-way connections, with each 
process involved being the initiator of one of the message 
groups. The sender and receiver of message text in a message 
group are thus uniquely determined by the message group name, 
therefore the model user need not type a process name when 
causing action to be taken to simulate the sending or receiving 
of message text. (Similarly, the sender and receiver of message 
text over an operator connection are uniquely determined because 
the model only allows message text to go from the operator to the 
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associated process.) 

Each node will need to maintain some information about the 
other nodes in the network. (It needs to know about remote pro- 
cesses that have requested access to at least one of its 
resources, and it needs some information about remote resources 
that have been requested by at least one of its processes.) The 
model is designed to create a set of node tables (one table for 
each node in the network) at each node in the network. Each node 
will use its set of node tables to maintain the information it 
needs about all the nodes in the network. 

Control messages are used by the model to simulate the 
transmission of most types of internodal messages. When a mes- 
sage must be sent between nodes, the model will cause text to be 
printed at the model user's terminal giving the model control 
message number and stating the destination node and what the 
message represents. At the time the model user would like the 
destination node to receive the message, he/she must issue a 
command to the model to receive the associated control message. 
OBPL's, message text within message groups, and resource 
allocation messages are all sent between nodes via control 
messages. This mechanism was selected so that the effect of 
internodal messages being delivered with varying delays could be 
simulated. The only internodal message that the model allows to 
be processed without user intervention is the one that would be 
associated with the initiating of a message group. There is no 
need to model the delay of a message for this because the node in 
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which the accepting process of the message group resides must be 
aware of the initiation before any checks for deadlock involving 
that message group will be made. 

The types of resource allocation messages that may pass be- 
tween nodes are 1) requests for access to remote database 
objects, 2) notification that a process has been granted access 
to a previously requested database object, and 3) notification 
that a process has released a database object. If the model user 
enters a process request for a remote database object, the model 
will block the process and send a control message (representing a 
remote resource request) to the node in which the desired 
database object resides. (Since deadlock detection is being 
modelled, and resource allocation need not be completely 
simulated, the model first looks across nodes to verify that the 
requested database object exists before it sends the control 
message.) After this control message is received and the desired 
database object can be allocated to the aforementioned process, a 
control message stating that the process has been allocated the 
desired resource is sent to the node in which the process 
resides. When this new control message is received, the process 
will be awakened. Although the release of database objects is 
not necessary to test an algorithm for deadlock detection, a 
command to allow a process to release a single database object 
was included in the model for debugging purposes. When a process 
releases a remote database object, a control message is sent to 
the node in which the database object resides. The model does 
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not simulate the automatic release of all resources controlled by 
a process at the time the process reaches a commitment point. 
This is a feature of process and resource management, and is not 
relevant to the simulation of a deadlock detection algorithm. 

In order to create deadlock situations, processes must be 
able to gain control of some database objects. The model uses a 
first-in-first-out allocation scheme for database objects. A 
process will be blocked if 1) it requests any type of access to a 
database object that has been exclusively assigned to another 
process, 2) it requests any type of access to a database object 
which already has other processes waiting for access to it, or 3) 
it requests exclusive use of a database object and some process 
currently has access to the desired database object. 

In order to adhere to the belief that the model should be as 
simple as possible, the model, in expanding an OBPL, does not use 
the decentralized algorithm exactly as described in the previous 
chapter. In step 10, the branch to step 3 was removed, thus step 
11 is always executed after step 10. When step 11 sends an OBPL 
to the node in which it is already located, further expansion 
takes place immediately. Steps 1 and 2 then get executed 
unnecessarily because RX is properly set in step 10, and the 
state tables have not been changed during the expansion of the 
OBPL so the last process to be inserted into the OBPL is still 
waiting for RX. This implementation was chosen to simplify the 
coding of the function definition algorithm used to expand 
OBPL's. 
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Appendix I contains a Data Structure Diagram for the 
deadlock detection model, plus a description of the entities and 
relationships shown in the Diagram. Appendix II contains a brief 
description of all the user visible functions in the model, fol- 
lowed by the PL/I code of the function definition algorithms 
which define the model. 

VII. 4 Test Cases run on the Model 

Using the model, several deadlock and near deadlock 
situations were entered to demonstrate various features of the 
deadlock detection algorithm. A feature Of the ADT system allows 
a user to save a series of commands in a file, and then type 
"scenario <file name>" to have the commands executed in order. 
In each of the cases given, after the system was reinitialized, 
but before the commands specific to each example were executed, 
the commands in file "demoO" were executed. The files, along 
with the output that resulted from the commands in the files, 
appear in Appendix III. The scenarios are well annotated, and it 
should be noted that commands to the system appear flush with the 
margin, whereas output from the Deadlock Detection Model is 
indented . 

The deadlocks created range from one involving two processes 
and two resources located in a single node, to some involving 
more than five processes or operators and more than four 
resources located throughout a three node network. By creating 
the same deadlock, but altering the order in which processes get 
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blocked and the order in which internodal messages are allowed to 
arrive, it is shown that the number of times the same deadlock is 
detected depends on how close (in time) some processes in the 
deadlock get blocked, and on the locations of the various pro- 
cesses and nodes. (The model works properly regardless of the 
"simultaneous" processing of commands at various nodes.) Appen- 
dix III also includes state diagrams for the test cases which 
appear in that Appendix. For the cases where a deadlock is cre- 
ated, only the final state is drawn (a key to understanding the 
diagrams is included), whereas for the cases where there is no 
deadlock, an important interim state is included in addition to 
the final state. 

The restriction stated in Chapter 4 that a process can not 
gain access to a database object, release it and request it again 
before reaching a commitment point, was included to rule out the 
situation that is shown in "demo_bug w . (The scenario was 
included for demonstration purposes only.) 
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VIII. Suggestions for Further Research 
After a deadlock is detected, at least one involved process 
must be forced to rescind its request for a resource that is 
controlled by another process involved in the deadlock. Some of 
the problems involved in breaking a deadlock < in particular when 
the deadlock is detected using the decentralized algorithm 
presented in Chapter VI) are discussed below, as are some issues 
that may lead to modifications in the schemes presented in 
Chapters V and VI. 

VIII. 1 The Rollback/Retry Problem 

In order to break a deadlock situation, at least one process 
involved in the deadlock must be selected and be forced to 
rollback (backup) to a state prior to the time at which it re- 
quested access to the resource for which it was waiting when the 
deadlock was detected. If the algorithm presented in Chapter VI 
is being used to detect deadlocks, then (due to the restriction 
that a process cannot release a database object when it is be- 
tween commitment points) the process selected for rollback must 
be returned to its most recent commitment point. In rolling back 
the process, the external effects created since the last process 
commitment point must be cancelled. 

To accomplish this rollback, it is necessary to undo all 
database object updates that the process performed within the 
scope of its current commitment unit (the period since its most 
recent commitment point), and then release all the database ob- 
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jects that were assigned to the process. In addition, all items 
of message text that were sent by the process in this commitment 
unit must be taken back, and all items of message text that were 
received by the process in this commitment unit must be requeued 
over the proper connections so that they may again be properly 
received after the process resumes execution. When taking an 
item of message text back, if it had already been received by the 
destination process, this destination process must also be rolled 
back to its most recent commitment point. 

Research needs to be performed to determine an efficient 
method for rolling back a process. It is possible that some 
constraints may have to be placed upon communicating processes in 
order to simplify the rollback problem and lessen the amount of 
information about a process that mUst be retained between 
commitment points. Some papers have been published that deal 
with the problem of rolling back a database to a previous state. 
(See rt] for one example.) 

Use of the deadlock detection algorithm described in Chapter 
VI can result in the same deadlock being detected more than once. 
It therefore may be useful to develop a deterministic algorithm 
for deciding which process should be rolled back, sp that addi- 
tional processes are not rolled back unnecessarily. Note that if 
OBPL's are created immediately after a process gets blocked, then 
every deadlock will be detected with an OBPL that contains only 
the involved processes. Thus even though. a process not involved 
in a particular deadlock may be waiting for access to a resource 
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which has been assigned to a process in the deadlock, no action 
need be taken when the deadlock is detected using an OBPL which 
contains more than the Involved processes. One possibility is to 
impose an arbitrary ordering on the nodes in the network, and 
always rollback a process in the lo**est numbered node that is 
involved in a given deadlock. This method is unfair in the sense 
that processes in t<he higher numbered nosles will rarely be forced 
to rollback to a previous state. Perhaps a fairer method is to 
attach a cost factor to each process entry in an OBPL. This cost 
factor will represent the cost (for the associated process) of 
computation to date in that process c**m*i!tme#it wiit. The process 
with the lowest cost factor will be rolled back with the hope 
that this minimizes the overall network cost of breaking the 
deadlock. It is also possible that when the same deadlock is 
detected more than once, it may be of^eaper < f rom the overall 
network cost viewpoint) to rollback an extra process 
occasionally, than to add the extra overhead that is needed for 
the methods mentioned above. This is a topic which needs to be 
s t ud i ed fur th er . 

Another related topic which can be investigated involves 
relaxing some of the restrictions dealing with the release of 
database objects so that a process can be rolled back to a state 
somewhere between the previous commitment point and the deadlock 
state. This may involve slight modifications to the algorithm 
described in Chapter VI, but may be useful because less code will 
have to be reexecuted after rollback. (It may be particularly 
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worthwhile when a process is executing a section of code where it 
is sequentially requesting access to several database objects 
before reading or updating any of them. Thus a partial, and 
perhaps sufficient rollback could be accomplished by the release 
of some of the database objects.) 

VIII. 2 Optimization and Expansion of the Decentralized Algorithm 

If OBPL's are created after a process has been blocked for 
»X» units of time (with 'X' greater than 0), then it may be pos- 
sible to occasionally eliminate the need to create an OBPL after 
a given process has been blocked for 'X' units of time. When a 
process is inserted into an OBPL before it has been blocked for 
•X' units of time, the need to create an OBPL with this process 
as the first entry is eliminated. (Additionally, the process may 
be granted access to the desired resource before 'X' units of 
time have elapsed, also eliminating the need to create an OBPL.) 
This type of implementation would affect the scheme used to break 
deadlocks, as there would no longer be the guarantee that each 
deadlock would be detected with an OBPL that only contains pro- 
cess entries for the involved processes. 

A restriction presented in Chapter IV prevents a process 
from requesting shared access to a database object and then 
requesting exclusive use of the same database object. It may be 
possible to allow this situation will little modification to the 
decentralized algorithm. 

The algorithm presented in Chapter VI requires that all 
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resources be uniquely identifiable. It may be desirable in some 
applications to allow processes to wait for any one of N 
identical and interchangeable resources. Inclusion of this 
property would necessitate a change in the use and expansion of 
OBPL's. Preliminary study shows that it would be necessary to 
place control of the expansion of an OPPL with one node (which 
may be different for each OBPL) , since notification would be re- 
quired after it is ascertained that a loop exists in an OBPL or 
that an active process has been encountered. This notification 
is needed because there is a deadlock involving N identical 
resources only if every process that controls one of these 
resources is involved in a loop in an OBPL. (This is in contrast 
to the situation where there are N readers of a given database 
object and a deadlock exists if any one of these readers is 
involved in a loop in an OBPL.) Rather than passing an OBPL from 
node to node, the "controlling** node may request other nodes to 
expand a section of the OBPL and return it to the "controlling" 
node. Further study is required to determine exactly how the 
decentralized algorithm can be modified to include the above 
mentioned feature. 

In addition, it may be worthwhile to study the possibilities 
of allowing human processes to wait for events external to the 
computer system (i.e. a phone call or a message from a fellow 
worker, rather than only wait for a message from a given process) 
and/or the possibilities of allowing a process to wait for more 
than one resource at a time. 
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VIII. 3 Types and Probability of Deadlock 

In order to get a valid estimation of the cost of using the 
deadlock detection algorithm presented in Chapter VI, it is nec- 
essary to get estimations as to how many processes in how many 
different nodes are typically involved in a deadlock, and how 
frequently deadlock can be expected to occur. Some research has 
been performed dealing with the probability of deadlock in a 
computer system (see C6]), but to this author's knowledge, no 
work has been performed dealing with the types (i.e. how many 
processes in how many different nodes) of deadlock that can be 
expected in a computer network. 

VIII.il Refinement of the Centralized Algorithm 

The scheme presented in Chapter V was not studied 
extensively. It is possible that it can be refined to a point 
where little, if any, unnecessary processing takes place in order 
to determine if a deadlock exists. Due to reliability factors 
and communications delays, it is not recommended that a 
centralized scheme be used exclusively in a network. However, a 
hybrid model of the centralized and decentralized algorithms may 
prove to be more cost effective than the decentralized algorithm 
alone. This hybrid model could possibly be constructed by using 
the centralized scheme for small groups of nodes located within a 
specified distance of each other, and then using the 
decentralized scheme between the control nodes for each of the 
groups using the centralized scheme. 
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IX. Conclusions 
The schemes presented in Chapters IX and III were designed 
to be used to help detect process deadlocks in a computer network 
where the only allowable wait condition Is ^r th* availability 
of database resources. *%ny sf*t**ir only Mt©# this type of 
process wait, so there is a need for algorithms which solve the 
problems trhat the schemes of ctfipt%r« II **tJ«f€I attack. 
However, some alterations must be made to the scheme of Chandra, 
Howe and Karp antf to? the decentralised scheme of Mahmoud and 
Riordon befor* they «aa be used to solve thirproolems they 
address. It seems that thes* two letiemei, when modified , would 
result in essentially the same algorithm. This new algorithm 
would require each node's resource tables to be sent to one node 
in the network, which will then process all the outstanding 
requests for access to database objects. (In the case of Mahmoud 
and Riordon's scheme, perhaps each node would still examine all 
requests.) The major difference from the original schemes is 
that no resource allocations would be performed without examining 
the entire network state, (i.e. requests for access by a process 
to local resources must still wait for information from other 
nodes) With or without modifications, the two schemes are 
inefficient in that they require large tables (when the database 
is locked at the record level) to be passed between the nodes. 
Additionally, each node must be capable of processing requests 
which require the presence of every node's tables in that node. 
This is an undesirable constraint, because it requires 
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minicomputers which serve as nodes within the network to have the 
capacity to store (in main memory or secondary storage) the 
entire network state at one time. Although only minor modifica- 
tions are required to the schemes so that they will work, they 
may require some major modifications before they can be used in a 
general scheme for detecting deadlock in all types (i.e. any size 
computers and any number of nodes) of computer networks. 

The two "centralized" schemes presented in Chapters III and 
V can both result in message bottlenecks at the control node, and 
if the control node fails, both result in a significant delay 
while a new control node is established. Additionally, if the 
network is geographically spread out, there can be an undesirable 
delay in some cases when a process requests access to a local 
database object. It is recommended that neither scheme be used 
exclusively in a network which covers a large (geographically) 
area or consists of a large number of nodes. 

The decentralized algorithm presented in Chapter VI requires 
each node to only maintain information relating to its processes 
and resources. Thus the amount of storage required at each node 
to support the algorithm is proportional to the total size of the 
system at that node. Additionally, there is little, if any, 
delay in granting a process access to an available resource. 

The size of messages (OBPL's) passed between the nodes is 
directly proportional to the number of processes involved in a 
chain, where each process is waiting for a resource controlled by 
another process in the chain. It is felt that these chains (and 
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therefore OBPL's) each involve only a few processes, and by 
delaying the creation of OBPL's until after a process has been 
blocked for *x« units of time, the number of OBPL's that must be 
passed between node* will be minimal. It stiould be noted that 
the decentralized algorithm presented in Chapter VI will work 
regardless of whether or not processes are allowed to wait for 
messages which must be sent from other processes within the net- 
work. 

With the optimization feature discussed earlier, the algo- 
rithm presented in Chapter VI is efficient and can be use 
regardless of the size and composition of a <M*«puter network. 
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Appendix I , Entity Descriptions 

This seotion desoribes the entities which ere used in the ADT Deadlock 
Detection Model. Each entity is described in basically the sane wanner. The 
foraat used is: 

<ENTITY MAME> 

> 

entity attributes: 
<attribute naae> 

<text 

> 

entity owner roles: 

<naae of set owned by entity> 

<text 

> 

entity amber roles: 

<naae of set where entity is a member> 

The sets are named in the following way: 

ovner_name->member_name 
Both owner_name and me*ber_name are the names of entities. A qualifier is 
used to distinguish between two set* which have the same entities as owner and 
member: 

owner_name->meaber_name( qualifier) 
If there are alternate owners or multiple members, the notation used is: 

owner_name/owner_name/. . .->member^ame/member^ame/. . . Where attribute 
naaes are used, they correspond exactly to the names (which include abbrevia- 
tions for the entities they represent) that are used in the fh/1 code of the 
Model. 

DATABASEjDBJBCT 

This represents an object within the ^ database which is subject to exclusive 
(read/write) or shareable (read only) aooess control. The object may be of 
various levels of granularity (file, page, record, or ttgg, off record) . The 
only requirement Is that the entire o&J«ot IS treated -Wiirormly in regard 
to assignment to a process and subsequent release. 

■■'-if-:; <£..._■■ '' 

entity attributes: 
d bo. name 

The unique name for the database object at the node in which it 
resides. 

entity owner roles: 

database_obJeot->database_obJeot_shared_asaignment 

Si 8L2 aqflm«irmUS&HB^'-f^l8BT^K%K^ 

read only basis. " 

database_obJeot->proce88 

The set of processes waiting on the availability of the database ob- 
ject. 

( see node_table/dbo/mes8age_group/operator_oonnect ion->procesa ) 
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entity member roles: 

node_table->database_object 

process->database_object 

DATABASE_OBJECT_SHARED_ASSIGNMENT 

The mechanism for recording the shared assignment of a database object to a 
process for read only purposes. 

entity_attributes: (none) 

entity owner roles: (none) 

entity member roles: 

database_obJect->database_object_shared_assignment 

process->databaae_object_shared_assignment 

MESSAGE_GROUP 

The string of text elements which are sent from one process to another over 
a specified connection. 

entity attributes: 
message. name 

The network unique name for the message group. 

message . numbered 

The number of messages in the message group that have been received 
by the acceptor of the message group plus the number of messages that 
are currently queued at the destination end and have not yet been 
received . 

message .number_rcvd 

The number of messages in the message group that have been received 
(read) by the acceptor of the message group. 

message . number_sent 

The number of messages in the message group that have been sent 
(regardless of whether or not they have currently reached the desti- 
nation node) by the initiator of the message group. 

entity owner roles: 

message_group->process 

The set of processes waiting for text in the message group. The na- 
ture of exclusive assignment of a message group to a process 
precludes more than one process to actually be waiting for text. 
( see node_table/dbo/message^roup/operator - eonnectlon->proeess) 

entity member roles: 

node_table->message_group( accept) 

node_table->message_group( init) 

process->message_group( receive) 

process->message_group( send) 

system->message_group 

MESSAGE_TEXT 

This represents one message within a message group when the initiator and 
acceptor are located in different nodes. No actual text need be 
transmitted, because for the purposes of deadlock detection, the content of 
the messages is unimportant, and it is only necessary to know how many 
messages are sent and received. 
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entity attributes: 
msg.mg_name 

The message group name to which the "simulated message" belongs. 

entity owner roles: (none) 

entity member roles: 
sy s tem- >me ssage_t ext 

NODE 

A processor in the network whioh includes a Process Management Module for 
the purposes of resource allocation and deadlock detection. 

entity attributes: 
node. name 

The network unique name for the node. 

entity owner roles: 
node->node_table 

The set of tables used by a node to maintain all needed information 
about the nodes in the network. 

entity member roles: 
system->node 

NODE_TABLE 

A table used to maintain needed information about operators, processes and 
resources located at a given node. 

entity attributes: 
node table . name 

The name of the node about which this table will maintain informa- 
tion. 

entity owner roles: 

node_table->database_object 

The set of database objects located in the node "referenced" by the 
node table, and for which the node in which the node table resides 
needs information. 

node table->message_group( accept) 

The set of message groups that have been initiated with the accepting 
process declared to be looated in the node which is "referenced" by 
the node table, and located therein. (If a node table does not 
"reference" the node in which it is located, then this set is empty 
for that node table . ) 

node_table->message_group( init) 

The set of message groups that have been initiated by processes lo- 
cated in the node which is "referenced" by the node table, and lo- 
cated therein. (If a node table does not "reference" the node in 
which it is located, then this set is empty for that node table.) 

node_table->operator 

The set of operators declared to exist at the node "referenced" by 
the node table, and for which the node in which the node table re- 
sides needs information. (A node only needs to know about the oper- 
ators at its own node, therefore if a node table noes not "reference" 
the node in which it is located, this set is empty for that node 
table.) 

node table->process 

The set of processes located in the node "referenced" by the node 
table, and for which the node in which the node table resides needs 
information. 
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node table/dbo/message_group/operator__conneetion->process 

The set of processes in a particular state. If the owner is a 
node_table which "references" the node In which it is looated, then 
the process is in the ready or running state. If the owner is a 
database object, the the prooess is waiting for access to that 
database object. If the owner is a message group or operator con- 
nection, then the process is waiting for text in that message group 
or over that operator connection. 

entity member roles: 
node->node_node_table 

OBPL 

An ordered blocked process list used to detect deadlock. 

entity attributes: 
obpl . res_name 

The name of the resource for which the most recently inserted process 
into the OBPL is waiting. 

obpl . res_node name 

The name or the node in which the above mentioned resource resides. 

obpl.res_type 

The type (database object, message in a message group, or message 
over an operator connection) of the above mentioned resource. 

obpl.msg_numb 



If the above mentioned resource is a message in a message group, then 
this attribute contains the number of the message (within the message 
group) that is being waitied for. 

entity owner roles: 

OBPL->OBPL_process_entry 

The set of processes and operators that have been inserted into the 
OBPL. 

OBPL_pass->OBPL 

operator->OBPL 

OBPL_PASS 

This is used to pass an OBPL from one node to another, where it can be 
further expanded. 

entity attributes: 

obplpass. des node_name 

The name of the node to which the OBPL is being sent for further 
expansion. 



entity owner roles: 

3PL 

Ls is a one-to-one relationship with the member being the OBPL 



OBPL_pass->OBPL 
Thia 
that is being passed from one node to another. 



entity member roles: 
system- >0BPL_pass 

0BPL_P ROCESS_ENTRY 

This represents a ppoeess that has been Inserted into an OBPL. 

entity attributes: 

proc entry . node_name 

The name of the node in which the process that has been entered into 
the OBPL resides. 

88 



Appendix I Entity Descriptions 

proeentry . prooes8_j3Me 

The naae of the prooess that has been entered into the OBPL. 

entity owner roles: (none) 

entity maber roles: 

0BPL->0BPL,_proee8S_entry 

OPERATOR 

This entity represents a person that has been deolared as an operator at a 
given node. 

entity attributes 
operator. naae 

The unique naae for the operator in the node at which he/she is lo- 
cated. 

entity owner roles: 
operator->OBPL 

The set of OBPb'a that require state inforaation about the operator 
before they can be further expanded. 

opera tor->operator_oonneet ion 

The set of operator connections over which the operator nay 
eoaaunioate with processes. 



entity aeaber roles: 
node_table->operator 

OPERATOR COMICTIOll 

An entity via which aessages are sent froa an operator to a process. 

entity attributes: 
op_oon.naae 

The network unique naae for the operator connection 

op_con.aua4>e**_q4 
"The nuaber of aessages that have been sent by the operator but have 
not yet been received by the process over this operator connection. 

entity owner roles: 

operator_oonneetion->proce88 

The set of processes waiting for text over the operator connection. 
The nature of exclusive aastgnaoiit of an operator connection to a 

?rooes8 precludes aore than one prooess to actually be waiting for 
ext. 

( see node_table/dbo/aessage_group/operator_ooatteotion->proees8 ) 



entity aeaber roles: 

opera tor->operator_conneot ion 

proceas->operator_aonnect ion 

sy8teav>operator_oonneot ion 



PROCESS (PROCESS COMMITMENT UNIT) 

This represents a proca a s which is executing within a prooess coaaitaent 
unit (the period between prooess ooaaitaent points). Processes are unique, 
as are process ooaaitaent units, therefore the aodel treats thea as one 
entity. 

entity attributes: 
process . acoesa_type 

If the prooess is waiting for access to a database object, this at- 
tribute denotes the type ("shared" or "exclusive*) of access desired. 
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process. naae 

The unique naae of the process within the node in which it resides. 

entity owner roles: 

proces8>>dsb«tase_ r pbject 

The set ©f database objects ourreMiy exeiasiTely aselgned to the 



!roeess for read/write purposes. If • database object is not 
nserted in such • set, end Its 
dat«bese_objeot.>dat«be3e objeot flh«red^,t s»1tnejenfr set is aap 



dat«bese_objeot.>dat«be3e object flh«red^,t s»1tnejenfr set is eapty, then 
it is available for exclusive seaigjsaeat, 

.^ectl»W^wi«n«ent entities representing 

The set ef msmc« frotifMi which have been accepted by the si 
(The process can receive aessagea la these aeasege groups.) 



proce»»~>d8tabase_pbjeot_ , _^___ iji4 

The set of databaie^oljeetusiSaJniCl^ entitle*. , - F — - v -r-= 
database objects assigned to a prnaais on a ajsared (read only) basis. 



process~>B»8sa£tjn*oup( send) 



The set of aessage groups which have been initiated by the process. 
(The process eaa aeod wc w scgc s in *h ss« —st ag* groups. ) 



_, connection 

i e set of, ?> * f* tor connections over which the process eaa receive 

seeeagee "ftflcsi ■• epdsatars. 

entity aeaber roles: 
node_teble->procese 

node_table/dbo/neseage_group/operator_oonnection->proee8s 

RESOURCEJEHMWT 

The internodal aessage granting a proeeas access to a database object lo- 
cated at a different node. 

entity attributesc 
res arant . pr oc_naae 

The naae ertbe process that is being given eeceae. to a database ob- 
ject . 

res xrant . proc_nodde naae 

The naae of the node in which the above jaantioaed p^eoeaa resides. 

resxrant . rea__ acne 

The. mum eTthe database object whiah the a|»ee> awntiened process is 

i^a—grant »rea_ncde v .ttajae 

The name oftho node in which the above aentioned database object 
resides. 

entity owner roles: (none) 

entity aoaber roles: 

8ysteB->resource_grant 

RESOURCE_RELBaSE 

The internodal aessage stating that a given database object has been re- 
leased by a specif led process. 

entity attributes: 

res rel.dest_dbo naae 

The naae of the database object being released. 

res rel . dest_node_naste 

The naae of the node in which the released database object resides. 
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resrel . rel_pnode_name 

The name of the node in which the process releasing the database ob- 
ject resides. 

res rel . rel_proe name 

The name of the prooess releasing the database object. 

entity owner roles: (none) 

entity member roles: 

8ystem->resource_release 

RESOURCEJREQUEST 

The internodal message in which a process requests access to a database 
object located at a different node. 

entity attributes: 
res req . aecess_type 

The type of access ("shared" or "exclusive") that has been requested. 

res req . dest_dbpjname 

The name of the database object to which aooess has been requested. 

resreq . dest_node_name 

The name of the node in which the desired database object resides. 

res req . req_pode_name 

The name of the node in which the requesting process resides. 

res req . reqjproc_jname 

The name of the prooess requesting access to the above mentioned 
database object. 

entity owner roles: (none) 

entity member roles: 

8y3tem->resource_request 

SYSTEM 

The computer network. 

entity attributes: 

system . last_cont_msg 

The number of internodal control messages that have been sent in the 
network. 

entity owner roles: 

system->message_group 

The set of message groups that have been initiated throughout the 
network. 

system->message_text/OBPL/pass/resouree_grant/resource_release/ 
resource_request 
The set of control messages that have been sent, but have not yet 
been received by the destination node. The type of control message 
represented is uniquely determined by the entity type of the member. 

system->node 

The set of nodes in the network. 

system->operator_connect ion 

The set of operator connections that have been declared within the 
network. 

entity member roles: (none) 
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Th« ADT Deadlock Detection Model eoiisiats of aoyea PL/I procedures, each 
of which contain* nultiple entries, a deecriptloa of the Deadlock Detection 
Model user visible functions begin* on tin aext safe. Included in the de- 
scription of a function 1* the naJM of Ilia o r ooo«oro .. In which . that function 
appears. The 99*m PL/J procedure* follow ttw fM n sHnn descriptions, and 
these procedures ere followed by the t*e fU% include f *!•# eM** "*r* used by 
the varioua procedures. Fll* DSH - eerv.jrouti»e» ©oatajaa declarations of 
Deadlock Detection Model, functions which are called by-other functions within 
the Model, and file aDT^prlaitives containa declarations of the ADT systea 
functions. 

The following is an Jade* to the PL/I aroaaduraa and include files. 

ADT_arl*itivee 144 
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Appendix II User Visible Functions 

USER VISIBLE FUNCTIONS 
ADT Deadlock Detection Mechanism 

acceptmg( p_mg_name , p_acoept_node_name , p_aocept_proo_name ) 
Declares prooess "p aeeept_proc_name" located in node 
"p_aecept_node_name" as the only process that can receive messages in the 
message group specified by "p_mg_name". aoceptmg is located within procedure 
MSG. 

cdbo( p node_name , p dbo_jname ) 

"Creates" a database objeot at the node specified by "p_node_name". The 
database object has a "local" name specified by "p_dbo_name". cdbo is located 
within procedure DDM. 

cnode ( p_node_name ) 

"Creates" a node with the name speoified by "p_node_name". cnode is lo- 
cated within procedure DDM. 

copeon(p_con_name, p_con_node_name , p_op name, p_process_name) 

■Creates" an operator connection between operator "p_op_name" and process 
"p_process_name", both located in node "p_con_node_name". The operator con- 
nection will have the global name specified by n p_con_name". copcon is lo- 
cated within procedure OP_CON. 

cproc(p_node_name, p_process_name) 

"Creates" a process with the name specified by "p_proeess_name" and lo- 
cated in the node speoified by "p_node_name". oproc is located within proce- 
dure DDM. 

dclop( p_op_node_name , p_operator_name ) 

"Declares" that an operator with name "p_operator name" exists at the 
node with name "p__op_node_name". dclop is located witKin procedure DDM. 

initmg(p mg_name, p_init_node_name, p_init_proo name , p_accept node name) 

Declares process "p_init Droc_name" located in node "p_lnit_noae name" as 
the only process that can sena messages in the message group specified by 
"P— mgjname". All messages in the message group will be sent to a process in 
the node specified by "p_accept_node_name" . initmg is located within proce- 
dure MSG. 



opmsg ( p_con name ) 
"Sends" a me 



message from the operator to the prooess in operator connection 
"p_con_name". opmsg is located within procedure OP_CON. 

opstat(p_op_node_name, p_op_name, p_state, p_con_name) 

States that operator "p op name" at node "p_op_node_name" is either 
"active" or "waiting" (specified by "p_state"). If the operator is waiting, 
it would like to receive a message from the process in operator connection 
"p_eon_name". opstat is located within procedure OP_CON. 

rcvcm( p_cont_jB3g_numb ) 

Causes the control message with number specified by "p_cont_msg_numb" to 
be received by the appropriate node and the required action then takes place, 
rcvcm is located within procedure RCV_CM. 

rcvmsg( p_mg_name ) 

Causes a message to be "received" in message group "p_mg_name". If no 
messages are queued, then the receiving prooess is blocked, rcvmsg is located 
within procedure MSG. 

r cvopmsg ( p_con_jname ) 

Causes a message to be "received" by the prooess in operator connection 
"P-.con.name". If no messages are queued, then the process is blocked and we 
request the status of the operator involved with this operator connection, 
rcvopmsg is located within procedure OP_CON. 
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Appendix II Procedure DDM 

d6m: procedure; 

/* This procedure is a collection of subroutines which either 
creates entities needed to model the deadlock detection algorithm proposed 
by Barry Goldman or performs servioes for other routines used in the model. 
The following user visible functions are included: 

CREATE DATABASE OBJECT 

CREATE NODE 

CREATE PROCESS 

CREATE SYSTEM 

DECLARE OPERATOR 
The following support routines are included: 

DECLARE DATABASE OBJECT 

DECLARE DATABASE OBJECT SHARED ASSIGNMENT 

DECLARE CONTROL MESSAGE 

DECLARE NODE TABLE 

DECLARE OBPL 

DECLARE OBPL CONTROL MESSAGE 

DECLARB PROCESS 

DECLARE PROCESS ENTRY 

DECLARE REMOTE RESOURCE GRANT 

FIND ENTITY LOCATION 

INITIATE OBPL •/ 
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del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
del 
(Include 



oont_jBsg_nuob 
dboref 
eos 
exp.obpl 

agref 

oewre* 
no__pore_nodes 
obpl_p««sref 
obplref 
opref 

p^attr_jB l«s«_jiaee 
p_eont_«ag__nuBb 
p_dbo_na»e 
p_dbo_node_nane 
p_del_eontj»sg_numb 



p_ec3L.dbo.jai 

p_dcl_entitY_eaea 

p_dcl_no<»e__tf*4_n 



p_dcl_entitY__Uae_.nane 



p_del_proe_na_e 

p_dcl_ref 

p_deatnode 

p_entity_jn« 

p_e»fcity_ref 

p_node_na_e 

p jobplr ef 

p__o|MHnBtieif^jMNn!' 

P^.Ofum»d«LjaMW 



p_proees8_n«M 
p_proe_nod«_neae 
p_rea_na_e 
p_res_node_naee 
p_jrea„t ypc ^ 
proe_enti*yr*f 
procref 
proc_ter_ref 
p_»end_nod«_nane 
P_aei_e UWLJMC 
r«a_jp»»nt.jrcf 
aec_node_na-e 
sec_noderef 
tableref 
fcepp_na_e 
teai_ref 
write_liat_ 
ADT_prl_itiveB; 



fixed bin: 

fixed % bln( 17); 

biM*b 

•ntpyt fixed bin( 17), char(12)); 

fixfd Bii 
bitO) 

?ss 

ehar7*E): 
fixed fcin; 

oh«r(i; 
_^ b 

ohar(20 

fixed bin (17); 

fixed^ Mn(l7): 
clar(»): 
fixed bind 7); 




ehaf, ,. 
ehar,l2); 
ohar 12); 
char 12); 
ohar(7); m % 
fixed bin(17i? 
fixed bine 17} ; 
fixed bin(17); 
char(12); 

fixe* bin (17): 
ehar(12); 
fixed bln(l7): 

eafciy ojptienalveriable) ; 
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/« CREATE DATABASE OBJECT 5/21/76 */ 

create database object: cdbo: entry(p_node_name, p_dbo_name); 
if fina_entity_Too(noderef, "sysOnode" , SYS_REF, p_node_name, "node. name") 
then do; 

call write list_( "Invalid node name. ", p_node_name, 
"does not exist."); 

return; 

end: 
eos = find entity_loc( tableref, "node->node_table" , noderef, p_node_name, 

"node_table . name" ) ; 
if find_entity_loc(dboref, "node->dbo", tableref, p_dbo_name, "dbo.name") 
then do: 

call write_list_( "Duplicate database object name"); 

return; 

end; 
call dcl_dbo(dboref, p_dbo_name); 

call insert (dboref, "node->dbo", "first", tableref); 
call write_list_( "Database object ", p_dbo_name, " created in node ", 

p_node_name) : 
return; 



/• CREATE MODE 5/19/76 */ 

create_node: cnode: entry(pnode_name); 
if owner (SYS_REP, "sys->node") 
then do: 

call write_list_( "Illegal request, system has not been created."); 
return: 
end; 
call find firs t_( noderef, "sys->node", SYS_REF, no_more_nodes) ; 
do while T no more nodes): 

if extractt noderef , "node. name") = p_node_name 
then do; 

call write_list_( "Duplicate node name"); 
return; 
end: 
call find_next_( noderef , "sys->node", no_more__nodes) ; 
end; 
call ereate_entity_( noderef , "node"); 

call create_at tribute (noderef, "node. name", "field", 12, p_node_name) ; 
call create_relationship_( noderef , "sys->node", "member"); 
call insert_( noderef, "sys->node", "first", SYS_REF): 
call create_relationship_( noderef , "node->node_table" , "owner"); 
call dcl_nodetable( tableref , p_node_name) ; 
call insert (tableref, "node->node_table" , "first", noderef); 

/* We will now make this new node "aware" of the existence of all 
other nodes, and make all other nodes "aware" of this new node. */ 
sec noderef s noderef; 

call find next_(sec_noderef, "sys->node", no_more_nodes) ; 
do while T no_pore nodes) : 

/• First create a table entity for the new node to be used by 

another node. •/ 
call dcl_node_ table (tableref , p_node_name) ; 

call insert (tableref, "node->node_table" , "first", see_noderef ) ; 
/• How create a table entity for an existing node to be used by the 

new node. •/ 
sec node_name = extract (see_noderef , "node. name"); 
call dcl_node_table( tableref, sec_node name) ; 
call insert_(tableref, "node->node table", "first", noderef); 
call find_next_(sec_noderef , "sys->node", no_more_nodes) ; 
end; 
call write_list_("Node created: ", p_node_name) ; 
return : 



97 



Appendix II 



Procedure DDM 



5/21/76 »/ 
|roe«as_name); 
, p_nede_name, "node. name ") 

r p_node_name , 



/• CREATE PROCESS 
create Droceas: cproc: entry (p_node_name 
if find_entity_loe(noderef, "sys->node", S 
then do: 

eall write list_( "Invalid node naae 

"dees not exist"); 
return: 
end: 
eos = find entity_loe{ tableref, B node->n©de_table" noderef, p node name, 

T node_table.»ame"); ~ 

if find entity_loc{proeref, "n0de->proeass" , tableref, p_proceas name, 
"process. name") ~ 

then do: 

call wrlte_llst_( "Duplicate process name"}; 

return; 

end; 
/* If an operator with the same name has been declared at the node, 

print an error message and return •/ 
if find_entity_loc<opref t *nede- Operator" tableref, Rjoroeess name, 

"operator. name") "~ 

then do: 

call write_list_(p_process_jiame, "has been previously declared", 
"as an operator at node", R_pode_name) ; 

return: 

end; 
eall dcl_proceats<procref r pBrocess_name) : 
call insertCproerer, "Bode-^proeess" , "first*, tableref); 
call i"?frt (procref, "node/dbo/mg-> process* "first*, tableref); 
call writa_Iist_( "Process*, pjprocess_naa» > 'created is node", p_node name); 
return; ' K " — ' 



5/t*/76 «/ 



/• CREATE SYSTEM 

if e sys-R^ tx = § ays: • 3Wsen: enfery; 

t¥en do: 

call write_list_C "System already created"); 

return: 

end; 
call ereate_entity_(SYS_REF, "system"); 

call create.attribute-CSYSREF. "system. last_coatj»g", "field", 10, 0); 
call create_relationshiiL.C5YSjEF, "sys->nodi"> "owner*); 

call create_relationship_/ < "" , *"" ■-— * — * - v 

call ereate_relationship_ 

call create_relationahip_ V v,*s«_««» , Qj>i-^mw»'. -%muwr-j 

call create relationship_(SYS_REF. "sys->ofi_«oa» r "owner"); 

call write_Tist_( "System created"); 

return: 



SYSREF, "sys->«sgMrp», "owner"); 

§J§— 5I F » "»y^>«©alreLpiesa*ge* "owner"); 

SYS_RBF, "ays->messafeV»owner*) ; 



5/27/76 */ 



/• DCL DBO 

del dbo: entry (p_dcl_ref , p_dcl dbo_name) : 

/» This procedure creates an entityy for a database object with name specified 
bv "n rfoi HhA n. M « «„,i «„-,..... *k- — — relationships. A reference 



by "p_dcl^dbo_jBams" and creates the necessary 

to the entity is returned via "p del/ref*. »/ 
eall create_entity_(p_del_ref, "dbo*): 
call create_attribute^(p_del ref, "dbo.name", "field" 
call ereate_relationship_(p_crcl_ref, "process->dbo" , "meml„ 
call ereate_relationship_(p_dcl_ref, "node->db©», "member"): 
call create_relationship_(p_dcl_ref, "dbo->dbo sh_asmt" "owner"); 
call create_relationship_(p_dcl_ref, "node/dbo7mg->process" , "owner"); 
return: 



x 12 j P_dcl_dbo_name) ; 
"member*) ; 
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/■ Da DBO SH ASMT 5/27/76 */ 

del_dbo_sh_asmt : entry (p_dcl_ref): 

/• This proeedure creates an entity for a database object shared assignment 

and returns a pointer to it via "p dcl_ref" •/ 
call create_entity_(p dclref, "dbo_sh_asm¥"); 

call create_relationsnip_Tp_dcl_ref, "proeess->dbo_sh_asmt", "member"); 
call create_relationship_(p_del_ref, "dbo->dbo_sh_asmt", "member"): 
return; 



/* Da CONTROL MESSAGE 5/27/76 */ 

dcl_control_message: entry (p_del_ref , p_dcl_entity_class_name, 
p_dcl_contmsg_numbT; 

/• This procedure will establish an OBPL, a remote resource request or a 
remote resource release as a control message. It will generate a control 
message number (which becomes an attribute of the entity specified by 
"p_dcl_ref* ) and change the "system entity so that it is aware of the 
new control message number. This control message number is returned via 
■p_dcl cont_ms« numb" */ 

p_deX_eont_msg_ numb = extract (SYS_REF, "system. last_cont_msg") + 1; 

call alter_(SiS_REF, "system .Tast_oont_msg" , p_dcl_cont msg_numb): 

call create_order (p_dcl_ref, p_dcl_entityelasa_name, "control_message"); 

call ereate_relationship_(p del ref7 "sys->eontrol_message" , "member";; 

call create_attribute_(p_dcl_ref, "control_message . number", "field", 10, 
p_dcl_cont_msg_nurab) ; 

return; 



/• Da NODE TABLE 5/27/76 •/ 

dclnode_table: entry (p_dcl_ref, p_del_node_tabl_name) ; 

/* This procedure will create an entity for a node table and creates the 
necessary relationships. The entity is also given the name specified 
"p_dcX_node_tabl_name" . A pointer to the new entity is returned via 
"P—del^ref* 1 . •/ 

call create_entity_(p_dcl_ref , "node_table" ) ; 

call ereate_attribute_(p dcl_ref , "node_table.name", "field", 12, 
p_dcl_node_tabTname) ; 

call create_relationship_Tp_dcl__ref , 

call create_relationship_(p_dcl^_ref, 

call ereate_relationship_(p_del_ref, 

call create_relationship_(p_de3 w ref, "node->clbo" , "owner"): 

call create_relationship_(p_del_ref, "node/dbo/mg->process", "owner"); 

call create_relationship_(p_dcl_ref, "init_node->message" , "owner"); 

call ereate_relationship_(p_dcl_ref , "aeoept_node->message", "owner"); 

return; 



by 



"node->node_table" , "member" ) ; 
"node->operator" , "owner" ) ; 
"node->process" , "owner" ) ; 



99 



Appendix II 



Procedure DDW 



flSSS 1 ' 



/• DECLARE OSPL 

entryCp^e^fDlref , p_rea_node_jrieee,, 
procedure will «reate en entity far 
entity will be ittrtlett field* " - _ " 

for the reewerae ttw6 tie iiievt 

is weitiitc for. f5e laiaClea e* t*e 

?araaeter 
crei 
eell creeteL 
call ereatajre 

call create_re^> VMn < v «w bu vK > , VV K^>»* » 
call ereatdj»ji*****"*tt* f» *fe»t».i*# *,- 

aall oreateiji* 

call oreat«L-a*«ri6e*«tJ 

/• Create an attirtlhele^ be altered ejtly 
to indicate tNe eeeaa i ga naaber with!* a 
waited f or */ 

call create_^at^^ Alwia e ^ g»L > ee^lref r »<M>»1, 

returns 



6/2k/76 •/ 




%ea»er*h 
r *ewner*) 



and node r 
>«£» OBPE, 
Via the 



» t2* p.res.naae) ; 



ttat rwaewmi ia 1 a acaeage) 

- gaxtjeevtaait n> being 



t *, •»»>! 



DECLAW 0«Pt, 



to b* 
node 

call ei _ 

call ereateLjtttt#tl 

fir, %jk 

call oreatejre. '"' 
/• Insert tlMr 
call insert^ Cl. 
/* Declare the 
call do _ 
call inaert 
call wrt 

call wr"' 
return; 



»/»/n •/ 



\xm tae 
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/• DECLARE OPERATOR 7/13/76 •/ 

dclop: entry(p_Op_node_name, p_operator name); 

/* This procedure will create an entity Tor an operator with name specified 
by "p_operator_name" and located at the node specified by 
"p_ob_node_name" */ 
/* If the node specified by "R_op_jnode_name" does not exist, print an 

error message and return •/ 
if find_entity loelnoderef, "sys->node" , SYS_REF, p_op_node_name , 
"node. name") 
then do; 

call write list_("Inmalid node name:", p_op_node_name , 

"does not exist"); 
return; 
end; 
/• Get the location of the node_table for "p_op node_name" •/ 
eos = find_entityloc( tableref, "node->node table" , noderef, 

p_op node_name, "node_table.name"T; 
/•If "p_operator_name" was previously declared as an operator, print an 

grror message and return */ 
if find_entity_loc(opref. "node->operator" , tableref, p_operator_name , 
"operator . name" ) 
then do: 

call write list_(poperator_name, "has been previously", 

'declared as an operator at node", p_op_node_name) ; 
return; 
end; 
/• If "p_operator_name" was previously declared as a process, print an 

grror message and return */ 
if find_entity_loc(procref, "node->process" , tableref, p_operator_name, 
"process. name") 
then do; 

call write list_(p_operator_name, "has been previously declared", 

"as a process at node", p_op_node_name) ; 
return; 
end; 
/• Create an entity for the operator and declare the necessary 
relationships and attributes */ 




call create_relationship_(opref, "node->operator", "member"); 

call insert (opref, "node->operator" , "first", tableref); 

call write Tist_(poperator_jtiame, "has been declared as an operator", 

"at node", p_op_node_name) ; 
return; 
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/• 
del 



DCL PROCESS 



it 



ed by m p^A«%jem 

e^etlhrabwfcei_f*ivlj 



oall ereate_relatien#fcip.j 
call create_j-elatiortafcip_ 
call create_relatiOfi«hip_ 
eall create_relati«iielttp_ 
eall create_reletlettSt»ip_ 
eall create_relatiooabip_ 
return: 




5/27/T6 •/ 
'if Mww>jr §i*« it felie name 



rocess: entryCp^deljref , p_dcl eroojiaae) ; 
/• This procedure will droate an entity fw a freeesw* s*t« « &»« «»■« 
apecifled by "p del frroj "name* and ufeaYa tfo fl ie si e ar y relationships 
eall eriftt ---■■ — -■ --- - 

call create^ 

P—dC^^— . w-^,. 

call create.attri&utt, 
call create_relat" 



•/ 



, •fie***, %2 , 



%Jto\jft, 
p_de2,J»ef, 




•ieaber"); 
<*•*§** "weaber"); 

■«**», •owner"); 

', •owner*); 
•owner*); 



/• DECLARE PROCESS ERTRT 

delj)roe_e«iifff m^m^jmpltm ', 
/• This procedure wilrlrietc m 

The entity will be Inserted into the 



%/nm 



and its **4mm'jm-wemfrti #f 
"p^r*»#e*yi**i* IMfci •p^pe^jfii 



call create_e«tit 
eall create^rw. '"~ 

eall ereatseuf^ 

call ereetovati 




an OBPL. 
Iref* 
by 
ana p_p i Pwo - _in 
tproe^oi&ryref, 

.Cproo^eotryre: 
•B_^eB*iyF'ei , 
' ie) * 
«^_ _ jyeatryref ; *$v&u*&9,*0**jmm*, •field", 

call inaert_{pre«_enTrryroTV*oWl*>f^^ *firet*, p^obplref); 

return: 



•aeaber"); 
• •field", 



/• DECLARE REMOTE RESOURCE GRiWT 6/t7/?6 •/ 

del_rem_rea_£ra»t: entr^(p_dbono<ie_naa#. p_dbo_jiaae f p_j>roc_n©d«_nan* ) 
p_oroe#aa_naBje , p idiiiTlaia aaatrj ; • 

/• This procedure will ereate aft e«tTty for a reaieto reeoere* allocation and 
then declare it as « control a o asage . Tft* ro i iui'oe r e pr e aegt ed by 
"p ' dbojsaae* at the node repi- e a e nc ed by ^ ^db^d^awjie* will be 
allocated to the proee** represented By * Or i laoij S»e* at the node 
representetf W ^_»roe_nOdo naeie". T^ e^rW^e*e*e nwtber will be 
returned via the parameter ^jSonlL 

eall create^etttity^Crowj^amt.jroT, "" 



*m 



*h 



call create^attril^e^(^e« 1 j5raii%>ef, frecjfrawt.rea_node_name", 

•«L.(r*i 
eall create attributeJrea - jgrartt_ i ref , "re«_«rant.proo_node_name", 



leaf AWftra^v* VHuQt antw^oii y . a- waj^0* ■■v** 

Laid", T27 p^d^jaeoXJ****); 
ittribute^(re»l u grajitJ , ef f "res_grant, 
Leld", 12, p_dbCLj»aii»> ; 



rae^naaw* 



•Field* 
oall createattr 

•Field 

;e attributed res - jirant_ i ref, "re 

"field*, f z, p^roc_jsode_j»aae) : 
call create attribute^ rea - grant_ i ref, "rea^r ant. pregnane", 

"field*, 127 P_pro©esa_«a«e) ; 
eall dcl_contiwl_a»saai«Trea_^rBnt_ref, "rea^jrant* , 

p_cont_jBsg_nuaib) ; 
eall insert_(res_£raat_ref, "ays^eontroUwsaage" , *laat", SYS_REF); 
return; 



162 



Appendix II Procedure DDM 

/* FIND ENTITY LOCATION 5/19/76 •/ 

find_entity_loc: entry(p_entity_ref, p_set_elass_naBe, p ownerref, 

p_entity name, p_attr_elassname) returns(bit(l7); 
/• This procedure determines the database address of the entity with name 
"p_entity_name" (specified by the attribute "p > attr_class_name") which 
is a member of the set occurrence (designated by the parameter 
"p_set_class_jname") owned by the record occurrence designated by 
"p_ownerref " . 

If the desired named entity does not exist, a true value ("1"b) is 
returned and "p_entityref* is unchanged. Otherwise a false value ("0"b) 
is returned and "p_entity_ref" is updated with the database address of 
the desired entity. */ 
ealj find_first_(temp_ref f p_aet_elass_name, p_ownerref, eos); 
if eos 

then do; 

temp name s extraet_( temp_ref , p_attr_class_name ) ; 
do while ( eos & (p entlty_name = temp_name)); 

calj f ind_next_Ttemp_ref , p_set_class_name, eos); 
if eos 

then temp_name * extract_(temp_ref, p_attr_elass_name) ; 
end; 
end; 
if eos then p_entity_ref s temp_ref; 
return (eos); 



/• INITIATE OBPL 6/25/76 •/ 

initiate_obpl: entry(p_proc node_name, p_proeess_name , p_res_node_name, 
p_res_name. p_res_type); 

/• This procedure will initiate the creation and expansion of an OBPL. The 
first process to be placed on the list is specified by "p _proeess_name" 
and is located in the node specified by "p_proc_node_name ir . The process 
is waiting for the resource specified by "p res_name" and located in 
the node specified by "p_res_node_name". The resource type ("dbo" or 
"message") is specified by "p_res_type" . •/ 

/* Create the OBPL entity and have it initialized with the resource and 

!rocess information given by the parameters. */ 
dcl_obpl(obplref . p_res_node_name , p_res_name, p_res_type); 
call dcI_proc_entry(obplref , p_proo__node_name, p_process_name) ; 
/* If the process Is waiting for a message, then we must find out the 
message number (within the message group) that is desired and put this 
information into the OBPL. In addition, if the process and the sender 
of the message are in different nodes, then we must send the OBPL to the 
node which initiated the message group rather than try to expand 
the OBPL right away •/ 
if p_res_type s "message" 
then do; 

/• Get the looation of the entity for the message group •/ 

eos = find entity_loc(mgref, "8ys->message", SYS_REF, p_res_name, 

"message. name") ; 
/* Get the number of the message desired */ 
message numb s extraot_(mgref, "message. number_qd") + 1; 
call alter_(obplref , - "obpI.msg_numb", message_numb) : 
if p_proc_node_name = p_res_node__name 
then do; 

call del_obpl_cont_msg(obplref, p_res_node_name, 

p_proc_node_name) ; 
return: 
end: 
end; 
/* Expand the OBPL as much as possible in this node */ 
call exp_obpl(obplref , p_res_node_name) ; 
return; 
end DDM; 
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REQ: procedure; 

/* This procedure oontains the subroutine which allows processes 
to request database objects for shared or mselmiMm use. the following 
user visible function is included: _, s* ,t ?»; 

REQUEST DATABASE OBJECT V 



del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

^include 

f include 



contjMW_nunb 

dboref 

dbo_ 

eos 

exo__oimerref 

ndn_proo_cwnerref 

p_aeoeas_trpe 

p_dbo_na«e ■■■•-#.£■; 

p_dbo_node_naa» 

pnoderef .*.«.■< 

p_process_ 

prbcrel 

ptableref 

resL_ree_ref 

shasatref 

writeJUst^ 
DDM serr rout ines ; 
ADTZprieiltiTes; 



fixed bin 
Mm* iia 
fJtad bin 

fixed Mn 
bitCU 





f ixest Basi t 
i*s# 



, htii ,M 

entry entionstvarlable); 
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/• . REQUEST DATABASE OBJECT 5/26/76 •/ 

request_dbo: p^bo: entry<p_acoes8_type, p_proc_node_name , p_proee88_naae , 



if fin<Lent^Uoe{pJMasr^^ays^ode*; SyXrEFT p_pr< 

then do: 

call write^list.^nvalid Drocess node name. ", p_proc_node_name , 

return; * ' 

end: 
/• Verify *JjJJ*Jj d J roc,8 f Jpeoified by "p_proee88_naae" exists at node 

eos = fiD4_«ntiIy_Ioo?ptataerjf. " node- > node. stable", pnoderef, 

if fin< ^ en «jSji^™?r' "*^« r >Pr*«es««, #iaM#|»#f, p T j>roceaa_nane, 



then do: 



then do: 

call vrite_liat_( "Invalid process nana", p r>roo«88_name , "at node", 

P_proc_node_naae, "does not «taC*TT 
return: 
end: 
/• yerify that access type is •shaped" op ""exclusive" •/ 

rhen f d^ W * " eTOlw4ir *"'* ^-• ? w «L k fyf« *» "shared") 

call vrite_list_( "Invalid access type, request not processed"); 
return; 
end: 
/•Check if the orooeaa is blooked •/ 

eail ™*t*^%J&&&k**/m& ?****»*, fbiw-oceasname, 

w at node", p_proc_node_j»a«e, "is not active. "); 
return; 

/• Check if the proc ess and reso urce are at the smae node. •/ 

then dos /•J^Prpoeaa and reaouroe are at the save node •/ 
/•Verify tnat the database objeot apeoif ig* ©y ? »p_dbo_na«e" 

if fin^eotity^locUbore?, "no^IiSboS, ptableref , p_db©_ha»e, 

then do: 

oall vrite_liat.J "Invalid database objeot nav* " 
n dbo_naae, i "at node", p_dbo_node_name 
"does not exist."): ' 

return; 

and; 

** T ?£--*?-f*f AiJ&P S^-**! l^****! **** aaatigned to the process*/ 



if inserted (dboref, "oroeess-XtboV 

then do; /•Cheek if Mw pro o ea a has exclusive control 

> . : : eSbsfee database object •/ 
call find ovn«r_(exc_o*fcerrer, "process->dbo" , dboref); 
if procref « exc^jswaaTpref-' •■;'••'■■■,■ 
then doi 

call write_list_( "Invalid request. Process", 
p_prooe»a name, "at node", 
p.proqnoJe^naae, "already has", 
"exclusive oontrol of", p_dbo_name, 
"at node", p_db«_node_nane); 
return; 
end; 
end; 
else do: 

/•Cfeeck if the process has shared access to the dbo •/ 
if eapty_intersection_( procref, "procesa->dbo_sh_asmt", 
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dboref, "dbo~>dbe^#IUM»*fc*) 
then do: 

call vrlt*JLl»tjL*Jnnl&4 request. Process", 

•at node", 



return: 




*m*te0nto has*. 
!jpaejav : *et node'", 







/• Check if the database object idffct Of available for 
if Inaertea^Uborcf, W*®**+*Fr^ aip&yJdboraf » 



assignment */ 



the process if the database o 
■asleimd rrr * — '" her i 
l * other proeesees a 

celJ mlxmrjL praaref , »i 



ins been 



no— fe y eiclueire use or 

•iWPltafcwJP- queued for the 



.«#04MML.tfpe*, 




>proeeas"); 
^process", "last", 



e^VwPsaVeH'iP'aFsWs' • e 



• ^SS^^ mKi 




end; 
/* Check if tiie request is for shared access */ 
if pj»cessf_tfpe * •sbarsd" 

"the* do; , /aQiye ttee sr^ss s aharad access to the desired 

», "first" , 

call insert^Csb^asafcref, "prooess->dbo_sh_as«t" , "first", 

eaii <^it»CXii^*P- J«^crssa J jwae f *at node*. 

p^pro cjsci l a^jf pWt * gaat ed shared access to", 

p„^fc«Upeas f ^st : Itopr* t ' p^ho,jaed^jtiae)e) 5 
return; 

/•The asKt.Il' stat w ent will be execut ed if the request is for 
exclusive use of the database object »/ 
^Wfr i Iy <IB3r P*" 00 *** **• *W, •«— P ** the desired database 
if «g*' r a £** or * f • *<»bo->dbojPbj»aa»") 

/•Queue the process for exclusive use of the database 
object because at ^— f t <»e^her igeof f « currently 



sai ss|^s: ?k&8S^So^ ! • -last- , 

call vrlte_llstjf%*a«iit*e is not currently available". 

•for exclusive use* process", p_j>rocess__nane}; 
call writa_listLj* „ at node", p_proc_node_nane, 

*is blocked."); 
call init)Uitc_obpi<pjro«_nodejiaae, p orocessjnaae, 



return; 
end: 
else do: 



p_dbc_jiode_naaa, p_dbo_naae,^ , dbo l 



iff 



call insert. 



/'Grant the process exclusive use of the desired 

database object. */ 
t_(dboref, "process->dbo" , "first", procref); 
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oall write_list.Jp__proce88_nsae, "at node", 

ft^proc^jiode_jiame # fit granted exclusive uae", 
■of" r R_dbo_name, "at node", p_dbo_node_name) ; 
return* 
end; 
end; 
/• The next section will be executed when a process requests a remote 

resouroe •/ 
/• Verify that the desired database objeet exists •/ 
if fimiLenti^loeUj^edmref, "sye->node" , *SY^REF r p_dbo_node_name, 

then do: 

oall write_liat_( "Invalid database object node name. ", 

P-dbojwdSiiiama* "does net exist."); 
return; 
end: 
eos = f ind,ent itv^oo < dbOL .t ableref , "node->node_table" , dbcuroderef , 

if find entTty_To^boref! *node->dbe'i n Jbo_Ubleref, p_dbo«name f "dbo.name") 
then do; 

ball write_liat_(*pfalid database object aaae . " . pudbojnaM , 

^at node"7 P_dbo_node_na*e, "doea not exist*"); 
return ; 
end: 
eos * fiiKL.entityJLoo(dbo_tableref > "node->node_table" , pnoderef, 
,. ^ , .^bojode.jwsw, "nodetable.najw"]; 
/• Check H^the node containing the process is aware of the existence of 

the desired database object. •/ 
if find entity.looCdboref, "node->dbo". dbo tableref, p_dbo_name, "dbo.name") 
then do; /• Create local information about the remote resource and 

block the process. •/ 
oall dol_dbo(dboref, p_ dbo__name); 

call insert? dboref, *node~>dbo" , "first", dbo.tableref); 
call alter.Tprooref, "process. access__type* , p_access_type) ; 
call remove T procref, *node/dbo/mg->proeess"); 
call insert_(prooref, "node/dbo/mg->process" , "last", dboref); 
end; 
else do; /• Check if the database objeet has already been assigned 

to the process. If it has, print sn error message, 
otherwise blook the process. •/ 
if inserted (dboref , "prooess->dbo") 
then do; 

call find owner_(exc_ownerref, "prooess->dbo" , dboref); 
if procref » exc_ownerref 
then do: 

osll write_J.ist_( "Invalid request. Process", 
p_processname, "at node", 
p_proc_JJOdejaame, "already has", 
"exclusive control of", p_dbo_name, 
"at node", p_dbo_jnode_name) ; 
return; 
end; 
end; 
else do; A 

if " empty lntersection_(procref, "process->dbo_sh_asmt", 
dboref, "dbo->dbo_sh_ssmt") 
then do: 

call write_liat_("Invslid request. Process", 

name, "at node", 
flLAame, "already has", 
red aoeeas to", p_dbo_name, 
"at node", pjdbo_node_name) ; 
return; 
end; 
end; 
/• Legal request, "block" the process. •/ 
call alter_ (procref, "process. acoess_type", p_acoess_type) : 
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call reB»ve_(procref, "n©de/dWa$->pr<>oa»a"):_. _ _ 

call insert^ precref, "nodWdbo/a|S->prooe»a" » "last", dboref); 

end; 
call vriteliat_("rre«eaf", p jrao « «E , 

"Is bToclced etolle a reeseasfc 
call write-lisCF **• «•*• oaShdSSm €*• §•»!*•* resource"); 

/• Create an eolity for *™**$« reacar ee r sawsa t and 'Win declare it 



call create_entitjr Jre*jree_ref, "i»t§jwaa*|f ■ 
call create_attribuie„ire», w req_ref, "rea_req.eeoeea_type" f "field", 9, 
p_acoeea_type ) ; _ _ 

mml; 



p_ecoeoa_t 

call creafce^jaaf 



. P_J>ro^node_jaa«B 
call create_attrToute__.(res. 



ft '*«MUWM|. 



", "field", 12, 



ref, "r«s_req.re^j>roc_Ba»«", "field", 12, 



call createrattrlb«Ie ,(re f_req_ref , »i*»jrf*#€e*tj*ellejMi»e" , "field", 12, 
call cre«tfcaUr|b^I(reVlreq_r«f, "ree^ref .dee*jf*ojM»e", "field", 12, 

call dcl_oo^ro]L S » i a *^ (re«_reerer, **<%iNi*i «2?Mt«-S! b 2i-v 
call inaert jrHj^Utf, "»ye-*i^rol^iieaii*, *Ua^T^iWLWr) 

■w» mill *•*»*. f* 



call write3i»0*Contr»i 

call writeluiCP 

return; 

end RBQ: 




»ient fie.", 
reediest") ; 
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%' 

MSG: procedure; 

/* This procedure contains the subroutines which perform the 
message management Functions for process to process communication within 
a network. The following user visible functions are included: 

ACCEPT MESSAGE GROUP 

INITIATE MESSAGE GROUP 

RECEIVE MESSAGE 

SEND MESSAGE •/ 



del aocept_node_name 

del accept_node_tableref 

del aceept_proc_name 

del aecept_procref 

del cont_msg_numb 

del eos 

del init_node_name 

del init_node_tableref 

del init_proe_name 

del init_procref 

del messageref 

del agref 

del ndm_proc_ownerref 

del noderef 

del p_aeoept_node_name 

del p_aocept_proc_name 

del p_init_node_name 

del p_init_proc_name 

del p_mg_name 

del procref 

del rev msg_numb 

del send_msg_numb 

del write_list_ 

{include DDM_serv_routines; 

{include ADT_primTtives; 



char(12); 

fixed bind 7): 

char(12); 

fixed bind 7); 

fixed bin; 

bit(1): 

char(12); 

fixed bin(17): 

ehar(12); 

fixed bind 7] 

fixed bin(1 7 

fixed bin(17 

fixed bin (17 

fixed bin(17J 

char(*J 

char(* 

chari* 

chart* 

char( # j 

fixed bind 7): 

fixed bin; 

fixed bin; 

entry options (variable): 
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/• ACCEPT MESSAGE GROUP 7/1/76 •/ 

acoeptmg: entry(pjft**jieae, p_acaept_node_naae , p_aeoept_j>roo_naae); 
/• After this prooedure is executed, the process specified by 
"p_aoeept_j>roc_name" (snd located at the node speoified by 



O the message 
$lM&**^**0*** e**st, print 



ii 



"p_aoceptjroo_name* (and located at the. node speoified 
/• If the message fr^flpWifMd -W*HJ*&***^M*0*»* < 



an error message and return */ 
if find_entity_lo©Ha»ref. *sYS->«esseie«, sniM^t- J fLMt^M0mi'' 
"message. name") ■ ~^. ■■■■- 

then do; 

call writfL.li*t.^(*InvaHd message group name: ", p_j»g_name, 

^ does not exist*}; 
return; 
end; 
/• If the message group has already teen accepted by a process, print an 

error message and return •/ ? -^> 

if inserted(mg>ef, *rcvg|*o^-?Sj*s^af«* )' 

eail e^ite lts% M (*Iif^lM'%N»ep« »)»s*age iroup. «. p_mg_name, 

^ has already Malt aeeepted&y I process*); 
return; ;- 1S/ 

end; ■•■■■"'• ""■«!> . • *"*•; -■■ - : - 

/• If the node specif if* by **j6M§tfr*lium0' M .-atf- 'fit accepting 
node that was specified waft tf» eSssag? group was initialised , 
print an error message '^mrtwPMWt ■■■■■■■• t?^ £■-.■-•■ 

call find_owner_(accepjC«0«l-ta»l«ref, "aooept_node*>measage" , mgref ) ; 
if p_accept_node_jname * e^*^lt.Pi*ei»t - mooe^i*iet , aT»'"'*i .name") 

then do: • « 

call writeJ.iat^(p_.accept^Ode - jiaae, * if nife the node that was " 

^ssecTfied to At \ fcjaijml».* #eh tfct message") 

call write llst^(" • was Initislised. The accept^", 

w request is rejected*); ; *-""-■ 

return; 
end; 
/•If the process specified by "p^ee^t^roc^name" does AC* exist 
at the node speoified by ^j&&j&$jMaii£pmM m , print ah er^hor 
message and rafurtt*/ 
if find_entity_loe(accept_procref, "node->prpoees" , aottept^node^tableref , 
p_aoeept - proc - .name, "process. name") 
then do; 

call write_liet_("Invslid process name: ", p_accept_proc_naae > 

Moes not exist at node ", p_aoeept_node_name) ; 
return; 
end: 
/•If the process accenting the message group is not active, print an error 

message and return */ 
call find_owner_(ndmjBroe - .ownerref, "node/dbo/mg->prooes8" , &ecept_procref ) ; 
if entity_ela88^aawZTttdsu>roc__ownerref) <■ *nooe_table* 
then do: 

call write^list^C "Invalid acoeptmg command. Process", 

p_aeoept_proc_j!jaae, "is not active"); 
return: 
end: 
/•If the process accepting the message group is the same one that 

initiated it, print an error message and return •/ 
call find_owner (init_node_tableref, w init_node->aeasage" , mgref); 
if init_node_tableref * aecept_node_tableref 
then do; 

/• The initiating and accepting nodes are the same. See if 

the initiating and aooepting processes are the same •/ 
call find_owner_Tinit_procref, "send_proe->message" , mgref); 
if init__proeref * accept_proeref 
then do: 

call write list ("Initiating and accepting processes", 
"are the same for message group ", p_mg_name, 
"acoeptmg oommand rejected"); 
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return ; 
end: 
end; 
/• Insert the message group entity into the accept set for the process 

specified by "p_aoeept_proc_name" •/ 
call insert (mgref, "rcv_proc->message", "first", accept_proeref ) ; 
call write list_(pjmg_name, " has been accepted by ", p_accept_proc_name , 

" at node "7 p_accept_node_name) ; 
return; 



/• INITIATE MESSAGE GROOP 7/1/76 «/ 

initmg: entry(p_mg_name, p_init_node_name , p_init_proc_name , 

p_accept_node_nane) ; 
/• This procedure will create a message group with the global name 
specified by "p_mg_name" . The only process that can send messages 
in this message group is specified by "p_init_proe_name" and is located 
at the node specified by "p_init_node_name". Wie process that will 
receive messages in the given message group is located in the 
node specified by "p_accept_node_name". The specific process that will 
accept the messages will be given in a subsequent call to "accepting" 
by the user. */ 
/* IF we have a duplicate message group name, we must print an error 

message and return •/ 
if find_entity_loc(mgref, "sys->message", SYS_REF, p_jng_name, "message. name") 
then do: 

call write list_( "Duplicate message group name, initmg", 

"command rejected"); 
return: 
end; 
/• If the node specified by "p_init_node__name" does not exist, print 

and error message and return */ 
if find_entity_loc(noderef, "sys->node", SYS_REF, p_init_node name, 
"node. name") 
then do: 

call write list_( "Invalid node name: ", p_init_node_name, 

" does not exist"); 
return; 
end; 
/* Get the location of the node_table for "p_init_node name" */ 
eos = find_entity_loc(init_node tableref, "node->node_Table" , noderef, 
,_ „„ p_init_node_name , "node_table.name"); 

/• If the process specified by "p_init_proc_name" does not exist at the 
node specified by "p_init_node_name", then print an error message 
and return •/ 
if find_entity loc(proeref, "node->proeess" , init_node_tableref, 
p_init_proc_name , "process. name") 
then do; 

call write list_( "Invalid process name: ", p_init_proc_name , 

" does not exist at ", p_init_node_name); 
return: 
end: 
/• If the process specified by "p_init_proc_name" is not active, print 

an error message and return •/ 
call f ind_owner_(ndm_proc_ownerref , "node/dbo/mg->process" , procref ) ; 
if entity_class_name_indm_proc_ownerref) *= "node_table" 
then do: 

call write_list ("Invalid initmg command. Process ", 

p_init_proe_name, " is not aotive"); 
return; 
end; 
/• If the node specified by "pacoept_node_name" does not exist, print 

an error message and return"/ 
if find_entity_loe(noderef, "sys->node", SYS_REF, p_accept_node_name , 
"node. name") 
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then do; 

call write list_( "Invalid node name: n , p_aecept_node_name , 
" does not exist"): 

return; 

end; 
/* Get the location of the node table for "p accept_node_name" */ 
eos r find_entity loc(aceept_node tableref, 'node-^node^.table" , noderef, 

p_accept_node_name , "node—table . name " ) ; 
/• Create an entity for a message group, create the necessary relationships 

and attributes, and insert the entity into the appropriate sets •/ 
call create_entity_( mgref . "message"); 

call create_relationship (mgref , "sys->message", "member"); 
call ereate_relationship_(mgref , "init_node->message", "member"): 
call create_relationship_(mgref , "accept_node->message", "member"); 
call create__relationship_(mgref , "send_proc->message", "member"); 
call create_relationship (mgref , "rcv_proc->me«sage", "member"): 
call create_relationship_(mgref , "node/dbo/mg->process". "owner"): 
call create_attribute (mgref, "message. number_sent", "field". 4, "0"); 
call ereate_attribute_(mgref , "message. number_qd", "field", A, "0"): 
call create_at tribute (mgref , "message. number_rcvd", "field", 4, "0"): 
call create_attribute_(mgref, "message. name*, "field*, 12, p_mg_name); 
call insert_(mgref, "sys->message", "first", SYS REF); 
call insert_(mgref, "init_node->message", "first", init_node_tableref ) ; 
call insert_(mgref, "accept__node->message". "first", accept node_tableref) : 
call insert (mgref , "send_proc->message", "first", procref): 
call write_list_( "Message group ", p_mg_name, "has been initiated"); 
return: 
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/• RECEIVE MESSAGE 7/1/76 •/ 

rcvmsg: entry (p_panajw); 

/• this pr^edure ^wTiraimulate the receiving of a message tn the message 

if f ind^entitffclocCBgref * *eys->neseage" , snURtf, Rjagjtiame, "message. name") 
then do; 

call write liat_( "invalid message group name: ", p_mg_name, 

^ does not exist"); 
return; 
end; 
/* If no process has accepted the message group, print an error message 

gnd return •/ 
if inserted (mgref, "rov_proc->message") 
then do; 

call vritelUM"I»**U<l renwg command. No process has", 

^accepted message group ", p_mg_na«e); 
return; 
endj 
; i? et >, t S t .! M>> f i P ?* of the process thai should receive the message •/ 

SftlgX mgr.f); 

accept nodcjaame « extracts (acoept_node_tableref. "node table. name"); 
/• If the process specifief by "aocept_proe_name* is met active, print 
an error message and return */ 

JS 11 fJP^^ #p -f nd C»^fe*p»#PrefV "no^/dba^iit->pro«iss«v aoeept_procref ) ; 
if entity_cla88_name_(ndmZjproc_o*merref) » •node_Ubl«" 
then do: _ ?3 . v _..",._. __; ', 

at node", 
**w* «w message o>n w /, 

_ _ message group", p_mg_nane): 

return; 
end* 
/• Find out if the message can be received, or if the process must 

be blocked •/■ ■ 
rcv_msg_numb « extraetjtmgref , "message. number re*d?>: 
rC th^ 88 ao^ < extraot_(mgref , "measage,fluaber_qd"} 

/•Allow^the process to receive the eeasage •/ 

oa fl**!f^^*?it^W»^«l»Jf^J^vd"i r^vjmafjoumb) ; 
call write_IisO •Process*; {^P^72r»ff?» •itnode", 

oall ■•mrtttjHuftJP' ' 'a message uTmessage group" , p_mg_name) 

return: 
end; 
else do: 

/• Block the process •/ 

call remoye^Caoceptprocref, "B«de/dbo/mg->proeess" ) : 

call in8ert_C*ooept_prooref, *node/dbo/mg->>prooese" , "first", 

call witOist_t*Process ", aocefttjrwuaewe, "at node", 
acoept node_namo, "is blocked waiting for a"); 



call writeJlifM^rooess", aooeptprocname, "i 

^ ac ?*l*-r2 0<,ei - niBa > *» •HflMfWt* Ho message osn be"); 
call write_list_T" received in message e 



°gll fiteJiC^ message pi messe^jgeoup". p^g_name); 

/• Get the nam* of the node tbaOniMmfeeOor "ouns^l^he message 

froup •/ 
. . ^ f ind_owner_( init_node tableref , "init_node->messa*e" , mgref) : 



froup •/ 
M , find_owner_(init_nodeL r tableref, *...„_ _ , _ ._- , 

inij^odensme * extract_(Tnlt_hode_tableref, "node_table.name"); 

/• Check tw deadlock *r 

call initiate_obpl(aceept_node_name, accept__proc_naae, 

inlt_node_name, pjsgjruime, "aesssge")} 
return; 
end: 
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/• SEND MESSAGE 7/1/76 •/ 

sendmsg : entry( p_mgname) : 

/* This procedure will simulate the sending of a message in the message 

froup specified by "p_mg_name" */ 
f the message group specified by "p_mg_,name" does not exist, print 
an error message and return */ 
if find_entity_lo©< mgref , "sys->fflessage" , SYSJREF, p_jng_name, "message. name") 
then do: 

call write li»t_( "Invalid message group name: ", p_mg_name, 

"does not exist"); 
return; 
end; 
/* Verify that the process that should send the message is active */ 
call find_owner_(init_proeref, "send_proc->me8sage", mgref); 
call find_pwner_(ndm_.proc_ownerref, "node/dbo/mg->process" , init_procref ) : 
if entity_class_name_J[ndm__proc_ownerref) « "node_table" 
then do; 

/* The process that should send the message is not active. Get 

its name and node and print an error message. */ 
call find_.owner_(init_node tableref, ■init__node->message", mgref); 
init_node_narae = extraet_(Tnit.ji©de_tableref, "node_.taple.name"); 
init_proc_name = extract_( init_proeref , "process. name"); 
call write list_( "Process ", iftit eroename , " at node ", 

Tnit node_name , " is not active. No message can be "); 
call write_list_(" sent in message group ", p_ag_name); 
return; 
end: 
/* Add 1 to the number of messages sent in this message group */ 
send _msg_ numb s extraet_(mgref , "message.number_sent"7 + 1; 
call alter_(mgref , "message. number_sent", send_msgnumb) ; 
/* Find out if the message must be sent between nodes */ 
call find_owner_(init_node tableref, "init_node->message" , mgref); 
call find_owner_Caccep£_node_tableref, "accept_node->message", mgref); 
if init_node_tab±eref s accept_node_fcablerer 
then do; 

/* Send a control message stating that a message has been sent in 

the message group specified by "pmg_name" */ 
call create_entity_Tmessageref, "msg"); 
call create_attribute_(messageref, "msg.mg_name", "field", 12, 

p_mg_name) ; 
call dcl_control_message(messageref, "msg", cont_msg_numb) ; 
call insert_.(nessageref, "sys->control_message" , "last", SYS_REF); 
/* Get the names of the nodes involved */ 

init__node_name * extract_(init_node_.tableref, •node_table.name"); 
acoept_.noaeL.name « extraet_(aeeept_no<!e_tableref, 

■node_t able . name") ; 
call writelist_( "Control message number ", eont_jnsg_numb, 

" sent from ", init_node_name, " to ", accept_node_name) ; 
call write list_(" representing a message in a message", 

"group" ) ; 
return; 
end: 
/* If the next section of code is executed, then the message should be sent 

between processes at the same node •/ 
/* The number of messages queued equals the number of messages sent because 

there is no delay across any node */ 
call alter_(mgref , "message. number_qd", send_.msg_.numb); 
call write_liat_("A message has been sent in message group ", p_mg_name): 
/* If no process has accepted the message group, return rather than see if 

a process should be woken up */ 
if * inserted_( mgref , "rcv_proe->message") 

then return: 
/• If a process is waiting for this message, wake it up and let it "receive" 

the message •/ 
call find_owner_(accept_procref , "rcv_proc->message", mgref); 
call find_owner_(ndm_proc_ownerref , "node/dbo/mg->process" , accept_procref ) ; 
if ndm_proc_ownerref a mgref 
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then do; 

/• Wake up the process pointed to by "accept_procref" •/ 

call remove_(aoeept_procref, "node/dbo/mg->process"); 

call insert_(aocept_procref, "node/dbo/mg->process" , "first", 

accept_node_tableref ) ; 
/* "Receive" the message •/ 

rev magnumb a extract_(mgref, "message. number_rcvd") + 1; 
call alter_(mgref , "message . number_rcvd" , rev_msgnumb) ; 
/* Get the name of the process that was awakened •/ 
accept_node_ name = extract (accept_j!iode_tableref , 

"node_table . name" 3 ; 
accept_proo name = extract_(aocept_procref, "process. name"); 
call write_Tist ("Process", aecept_proc_name , "at node", 

accept node_name, "has been awakened upon"); 
call write_list_T" v receipt of a message in message group", 

p_mg_name) ; 
end; 
return : 
end MSG: 
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Procedure 0P_C0N 



OP CON: procedure; 

/•""This procedure contains subroutines which create an operator connection, 
allow the operator to send messages over the connection, allow the 
operator to receive messages over the connection, and allow the 
operator to report its status (active or blocked) with respect to the 
operator connection. The following user visible functions are included: 

CREATE OPERATOR CONNECTION 

OPERATOR MESSAGE 

OPERATOR STATUS 

RECEIVE OPERATOR MESSAGE •/ 



del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

^include 

finclude 



con_opref 

eos 

n dm_proc_own er re f 

node re f 

node_tableref 

number qd 

obplrer 

op_eonref 

opref 

p_con_name 

p_con_node_name 

p_op_name 

p_op_node_name 

p_proeess_name 

process name 

p roc_node_neme 

proeref 

p_state 

tableref 

write_list_ 
DDM_serv routines : 
ADT_primTtives : 



fixed bind 7); 
bit(1); , % 
fixed bin(17): 
fixed bin(17); 

bin(17): 

bin: 

bin(17); 
17); 



fixed 

fixed 

fixed 

fixed 

fixed 

char 

char 

ohar 

char 

char 

char 

char 



bln(' , 
bin(173 



ii 



12 
.12] , 

fixed bind 7): 

ehar(*); 

fixed bind 7); 

entry options(variable); 



/* CREATE OPERATOR CONNECTION 7/9/76 •/ 

copcon: entry(p_eon_name, p_con_node_name , p_op_jname, p_process_name) ; 
/• This procedure will create a connection between the operator specified 
by "p_op_name" and the process specified by "p_proeess_name" , both 
located at the node specified by "p_op_nodename". The connection will 
be given the name specified by "p_con_name" •/ 
/* If we have a duplicate operator connection name, print an error message 

and return */ 
if find_entity_loc(op conref, "sys->op_con" , SYS_REF, p_con_name, 
B op_con.name ir ) 
then do: 

call write list_( "Duplicate operator connection name.", 

"Command rejected"); 
return; 
end; 
/* If the node specified by "p_con_node_name" does not exist, print an 

error message and return */ 
if find_entity_loe(noderef , "sys->node", SYS_REF, p_eon_node_name , 
"node. name") 
then do: 

call write list_( "Invalid node name:", p_con_node_name , 

"does not exist"); 
return; 
end; 
/• Get the location of the node_table for "p_con_node_name" •/ 
eos = find_entity_loc(node_tableref , "node->node_table" , noderef, 
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/. t* .... P_eonnode_name , "node_table.name"): 

/•If the node Is unaware of the existence of the operator, print an 

error message and return •/ 
if find_entity_loo(opref, "node->operator" , node tableref, p op name, 
"operator. name") ~ 

then do; 

call write list_( "Invalid operator name:", p op_name, 
"does not exist at node", p connoae name); 
return; ~ ~ 

end; 
/* If the process specified by "p_prooess_name" does not exist at the 
m. 2? d 5 specified by "p_con_node_name", print an error message and return •/ 
if find_entity_loc(procref. "node->process" , node_tableref , 
p_proces8_name , "process . name" ) 
then do; 

call write list_( "Invalid process name:", p_process name , 

"does not exist at node", p_con__node nameT; 
return; ~~ 

end; 
/• If the process specified by "p_process_name" is not active, print an 

error message and return •/ 
95 11 f}p d -O wn er_(ndm_proe_ownerref, "node/dbo/mg->process" , procref); 
if entity_class_name_(ndm_proe_ownerref) s "node table" 
then do; 

call write list_( "Invalid eopeon command. Process", p_process name, 

"is not active"); ~ 

return; 
end; 
/* Create an entity for an operator connection and insert it into the 

5 roper sets •/ 
create_entity_(op oonref, "op con"); 
call create_attribute_Top_eonref, "op_con.name", "field", 12, p conname); 
call create_attribute_(op eonref, "op eon. number qd", "field*, Tf, "0")7 
call create_relationsnip_Top_conref, "prooess->op con", "member"}: 
call create_relationahip_{op_eonref, "operator->op eon", "member"); 
call ereate_relationship_(op_eonref, "sys->op_oon"7 "member"); 
cell create^elationship^vopLjoonrefj "node/dbo/mg->process", "owner"): 

prooref) ; 




call insert (obconref, "sys->op_con", "first", STS_REF); 

call write_JList_( "Operator connection", p_conname, "has been established"); 



return; 
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opmsg : 
/• Thii 



/• OPERATOR MESSAGE 7/13/76 •/ 

nag: entry(p_oonname) ; 

This procedure will cause a message to be sent from an operator to a 
process over the operator connection specified by "p.jjoajmum". If a 
process is waiting for this message, it will be awakened and given 
the message, otherwise the message will be queued. Any OBPL's that 
were waiting for state information about the operator with respect to 
this operator connection will be discarded since the operator is active ■/ 
/• If the operator connection specified by "p_con_name" does not exist, 

print an error message and return •/ 
if find_entity_loc(op_conref, "sys->op_eon", SYSJREF, p_eon_name, 
"op_con.name") 
then do; 

call write_list_( "Invalid operator connection name:", 

p_con_name, "does not exist"); 
return: 
end; 
/• Discard any OBPL's that were waiting for state information from the 

operator tnat sent the message */ 
call find_owner_( opref, "operator->op_con" , op_conref); 
call find firs t_( obplref, "operator->obpl", opref, eos); 
do while T eos); 

call remove (obplref , "operate r->obpl"); 
call find_first_( obplref, "operator->obpl", opref, eos); 
end : 
/* If no process is waiting for the message, queue it an return ■/ 
if empty_(op_conref, "node/dbo/mg->process" ) 
then do: 

number qd = extraet_(op conref, " op_con. number qd") ♦ 1; 
call aTter_(op^conref, *op_eon. numbered", number_qd); 
call write list ("No process is waiting for the message,", 

"so ft is queued"); 
return: 
end; 
/• A process is waiting for the message, so we must wake it up */ 
call find_first_(procref, "node/dbo/mg->process*, op_conref, eos); 
call remove_( procref. "node/dbo/mg->proeess"); 
call find_owner_(tableref , "node->process*, procref); 
call insert_(proeref, "node/dbo/mg->process" , "first", tableref); 
/* Get the name of the process that was awakened */ 
process name = ext ract_T procref , "process. name"); 
proe_node_name s extract_ (tableref , "node__ta,ble.name"); 
call write_list_(process_name, "at node", pr©e_node_name , "has been", 

"awakened upon") ; 
call write_list_(" receipt of a message over operator connection", 

p_con_name); 
return: 
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/* OPERATOR STATUS 7/14/76 •/ 

opstat: entry (p_op _node_naae, p_op_name, p_state, p con_name): 

/» This procedure will take the appropriate action when an operator 

reports that it is "active" or "waiting" •/ 
/* If the node specified by "p_op_node_name" does not exist, print an 

error message and return •/ 
if find_entity_loe(noderef, "ays->node", SYS_REF, p_op_node_name, 
"node. name") 
then do; 

call write list_( "Invalid node name:", p_op_node_name , 

"does not exist"); 
return; 
end; 
/* Get the location of the node table for the node specified by 

"p_op_node_name" •/ 
eos = flnd_entity loc(tableref, "node->node table" , noderef, 

p_op_node_name, "node_table.name"7; 
/* if the operator specified by "p_op_name" does not exist at the given 

node, print an error message and return */ 
if find_entity_loe(opref, "node->operator" , tableref, p_op_name, 
"operator . name" ) 
then do; 

call write list_( "Invalid operator name:", p_op_name, 

"does not exist"); 
return; 
end; 
/• If the operator is active, we can discard all OBPL's that desired this 

state information, and then return •/ 
if p_state = "active" 
then do; 

call findjrjrst (obplref, "operator->obpl" , opref, eos); 
do while ( eosT; 

call remove (obplref. "operator->obpl"); 
call find_first_( obplref, "operator->obpl", opref, eos); 
end; 
call write list_( "All OBPL's waiting for the given state", 

"information have been discarded"); 
return: 
end; 
if p_state = "waiting" 
then do: 

call write list_( "Invalid state. An operator can only be", 

"active or waiting"); 
return; 
end; 
/* If the operator connection specified by "p_eon_name" does not exist, 
print an error message and return because one can not wait for a 
message over a non_exi stent operator connection */ 
if find_entity_loc(op_conref, "sys->op_con" , SYS_REF, p_con_name, 
"op_con.name") 
then do: 

call write_list_( "Invalid operator connection name:", 

P_con_name, "does not exist"); 
return; 
end: 
/• If the operator specified by "p_op_name" is not involved with the 
operator connection specified by "p_con_name", print an error message 
and return •/ 
call find w owner_(conopref, "operator- >op_con" , op_conref); 
if opref r con_opref 
then do: 

call write list_(p_op_name, "at node", p_op_node_name, 
"is not associated with operator connection", 
P_con_name) ; 
return; 
end; 
call write_list_("We will now check for deadlock involving the given", 
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"operator"); 
call write_list_(" and operator connection"); 
/• If the process that can send messages over the operator connection 
specified by "peon name" is active, there is no deadlock, so 
discard all OBPL's that requested the given state information •/ 
call find_owner_(proeref , "process->op_eon". op_eonref); 
call f ind_owner_(ndmoroe_ownerref , "node/dbo/mg->process" , procref): 
if entity_class_namentpdm r j>roc_ownerref) * "node_table" 
then do: ^ 

call find_fjrst (obplref, "operator->obpl", opref, eos); 
do while ( eosT: 

call remove (obplref. "operator->obpl") ; 
call find_first_(obplref, "operator->obpl", opref, eos); 
end; 
return; 
end; 
/* If there are no OBPL's waiting for state information about this 

operator, create an OBPL with the operator as the only process entry •/ 
if empty_( opref, "operator- >obpl") 
then do; 

call del__obpl( obplref, p_op_node,i*a*e , ••, "op_msg"); 
call del_4>roc_entry (obplref, p_ opjsode.jiame , P-Opjiame): 
eall inaert_( obplref, "operator->obpl», "first", opref); 
end; 
/* Find out the name of the process that can send the message the 

operator desires •/ ' ■ % 

process_name * extraet_( procref, "process.naoe"): 
/* Expand each OBPL that required state information about the given 

operator ♦/ ' 
call find first_( obplref, "operator->obpl», opref, eos); 
do while T eos) ; 

/* Remove the OBPL from the set belonging to the given operator •/ 

call remove_( obplref , "operator- >o*pi* j ; 

/* Check if we have a deadlock */ 

call eheck_for_deadlock(obplref, p^Ofc^od^L^ime, process name, eos); 

/•If eos » 1, theft a deadlock was not detected, so we should add a 

resource to the OBPL and then expand it */ 
if eos 

then do: 

call obpl_add_resource(obplref , ndnu>roc_ownerref , 

p_op node_name, ees)$ 
/• If eos s 1 then the resource the process is waiting for 
is in the same node as the process, so we can continue 
to expand the OBPL •/ 
if eos 

then call exp_obpl( obplref, p_op_node_name) ; 
end; 
/* See if there are any more OBPL's to be examined */ 
call find_first_( obplref, "opera tor->obpl*, opref, eos); 
end; 
return; 
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/• RECEIVE OPERATOR MESSAGE 7/13/76 */ 

rcvopmsg: entry (p_eon_name) ; 




print an error message and return •/ 
if find_entity_loc(op_conref, "sys->op_con" , SYS_REF, p_con_name, 
w op_con.name") 
then do: 

call write list_( "Invalid operator connection name:", p_con_name, 

"does not exist"); 
return; 
end; 
/• Get the name and node of the process that should receive the message */ 
call find_owner_(procref, "process->op_con" , op conref); 
process_name a extraot_( procref, "process. name"7; 
call find_owner_(tableref, "node-process", procref): 
proc node_name a extract_(tableref , "node_table.name"); 
/• If the process is not active, print an error message and return •/ 
call find_owner_(ndm_proo_ownerref, "node/dbo/mg->process" , procref); 
if entity_class_name_J[ndnLjproc_ownerref) a "node_table" 
then do: 

call write_list_( "Process", process_name , "at node", 

proc_node_name , "is not active. No message can be"); 
call write_list_(" received over operator connection", 

p_eon_name) ; 
return; 
end; 
/* Find out if the message can be received, or if the process must be 

blocked •/ 
number qd = extraet_(op_conref , "op_con.number_qd"); 
if number_qd > 
then do; 

/* Remove one message from the queue */ 

number qd a number_qd - 1 ; 

call alter_( op conref, "op_eon.number._qd", numbered); 

call write list_(process_name, "at node", proc_node_name , 

"has received a message"); 
call write_list_(" over operator connection", p_con_name); 
return; 
end; 
else do: 

/• Block the process and initiate processing of an OBPL */ 

call remove_( procref, "node/dbo/mg->process"); 

call insert_( procref, "node/dbo/mg->proeess" , "first", 

op conref ) ; 
call write_list_( "Process", process_name. "at node", 

proc_node_jiame , "is blocked waiting for a"); 
call write_list_(" message over operator connection", 

p_con name) : 
call initiate_obpl(proc_node_name, process_name , proc_node_name , 

p_con_name , "op_msg" ) ; 
return; 
end; 
end OP CON; 



121 



Appendix II 



Procedure RCV_CM 



t: 

RCV_CM: procedure t L , ,_, ,_ , ,, 

/• This procedure is a collection of subroutines which will accept 
a control message and take the appropriate action. The following user 
visible function is included: 

RECEIVE CONTROL, MESSAGE 
The following support routines are included: 

PROCESS MESSAGE 

PROCESS OBPL PASS 

PROCESS "PROCESS TERMINATION" 

PROCESS RESOURCE GRANT 

PROCESS RESOURCE RELEASE 

PROCESS RESOURCE REQUEST •/ 



del accept_node_name 

del acoept_node_tableref 

del accept_proc_na»e 

del accept-Procref 

del aecess3yP« 

del cont_msg_numb 

del cont_msgref 

del cont_msg_type 

del dbo_naae 

del dbo_node_name 

del dbo_noderef 

del dboref 

del dbo_tableref 

del eos 

del mg_name 

del mgref 

del nam Droc_ownerref 

del obplref 

del p_eont_msg_numb 

del p_msgref 

del p_obpl_passref 

del p_res_jgrantref 

del p_res_relref 

del p_res_reqref 

del process name 

del proc_node_name 

del proc_noderef 

del procref 

del proc_tableref 

del qd_msg_numb 

del rcv_mag_numb 

del rcv_node_jiame 

del sh_asmtref 

del write_list_ 

^include DDM_serv rout ines ; 

^include ADT_primltives; 



chart 12): % 

fixed bin(17); 

char(12): \ 

fixed bin(17): 

ehar(9): 

fixed bin: % 

fixed bin(17): 

char (20); 

chary 12); 

chard 2): % 

fixed bin(17, 

fixed bin(17, 

fixed bin(17J 

bit(1): 

char(l2); 

fixed bin(17) 

fixed bin(17 

fixed bin< 17) 

chart*); 

fixed bin(i7 

fixed bin(17 

fixed bin(17 

fixed bin (17 

fixed bin<17) 

char (12); 

ehar(12); % 

fixed bin(17); 

fixed bin(17); 

fixed bin<17); 

fixed bin; 

fixed bin; 

char(12): 

fixed bind7); 

entry opt ions (variable); 



/• RECEIVE CONTROL MESSAGE 6/15/76 •/ 

receive_control_message: revem: entry (p_eont_jnsg_numb); 

/• This procedure will verify that the control message which has its number 

specified by "p cont msgnumb" has been sent, but has not been received. 

The procedure will then determine what type of oontrol message it is, and 

the appropriate subroutine will be called to act on the message. •/ 
call find_first_(cont msgref , n sys->oontrol_message" , SYS_REF, eos); 
/* Convert the control message number from a character string to a numeric 

value */ 
cont_msg_numb = p_cont_msg_numb : 
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/* Find thg control message with number specified by w p cont msgnumb" •/ 
do while ( eos); ~~ 

if extract (cont_msgref, "control_message. number") = contmsgnumb 
then do: 

/• Remove the oontrol message from the set of control messages 
so that this control message will not be received a seoond 
time •/ 
call remove_(cont_msgref , "sys->control_message" ) ; 
/■ Find out what type of control message it is, and call the 

routine that will take, the appropriate action •/ 
cont_mag_type a entity_elass_name__(cont_jnsgref); 
if eont_msg_type s "msg" 
then do; 

call write_list ("Control message_number" , 

p cont_jBsg_numb, "representing a message", 
"in a message group"); 
call write_list_(" has been received"); 
call process_msg(cont_msgref ) ; 
return ; 
end; 
if cont_msg_type s "obpl_pass" 
then do: 

call write_list_( "Control message number", 

p cont_msg_numb, "representing an OBPL", 
"has been received.";; 
call process_obpl_pass(cont_msgref ) ; 
return; 
end; 
if cont_msg_type r "res_grant" 
then do: 

call write_list ("Control message number", 

p_cont_msg_numb , "representing a remote", 
"resource allocation"); 
call write_list_(" has been received"): 
oall proeess_re3_grant(cont_msgref ) ; 
return : 
end; 
if cont_msg_type = "res_rel" 
then do: 

call write_list ("Control message number", 

p_cont_msg_numb , "representing a remote", 
"resource release"); 
call write_list_(" has been received"); 
call process_res_rel(cont_msgref ) : 
return; 
end; 
if cont_msg_type = "res_req" 
then do: 

call write_list_( "Control message number", 

p__cont_msg_numb , "representing a remote", 
"resource request"); 
oall write_list_(" has been received"); 
call process_res_req(cont_msgref ) ; 
return: 
end: 
end: 
call find_next_(eont_msgref , "sys->control_message" , eos): 
end; 
/• If "p_cont_msg_numb" didn't match any control message number, then we 

should print an error message and return •/ 
call write list_(pcont_msgnumb, " is not a valid control message number.", 

" Command rejected"); 
return: 
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/» PROCESS MESSAGE 7/1/76 */ 

process_msg: entry (pmagref ) : 

/* This procedure will receive a message in a message group. If a process 



process_msg: entry (pmagref) 

'" This procedure will receive a message in a message g: 

is waiting for this message, it will be woken up, otherwise the message 



/• Get the name and location of the message group */ 

agjnaae = extraet_(p_msgref , "msg.mg_name"); 

eos « find entity_loc(mgref, "sys->mesaage" , SY2LREF, mg_name, 

"message. name*) ; 
/• Acknowledge receipt of the message by adding 1 to the number of messages 

that have been queued in this message group •/ 
qd msgnumb a extraet_( mgref , "message. numher_qd") ♦ 1; 
call alter_(mgref, "message. number_qd", qd_msg_numb) ; 
/• Jf no process has accepted the message group* return */ 
if inserted_(mgref, »rev_proc->message") 
then do; 

call write list__( "Message group", mg_name, "has not been", 

"accepted. The message is queued."): 
return; 
end ; 
/• Get the name and node of the process that can receive the message */ 
call find_owner_(accept_procref, "rcv_proo->*essage", mgref); 
accept_proc_name a extract (accept_procref , "process. name"); 
call find_owner_(accept,jf»oae_tableref. "accept_node->message" , mgref); 
accept_node_name » extract_(aecept_node - .tableref, "aode_taDle.name"); 
/• Keep the message queued if the process is not waiting for it. Otherwise 

wakeup the process. •/ 
call find_owner_(ndaL4froc_ ownerref, "node/dbo/mg-Xprocess" , accept_procref ) ; 
if ndm_proc_owierref = mgref 

then call write list_( "No process is waiting for the message, ", 

"so it is queued"); 
else do; 

call remove (aeeept_procref, "node/dbo/mg->process"): 

call insert__(acceptprocref, "node/dbo/mg->process" , "first", 

aeeept_node_tableref ) : 
rev msgnumb = extraet_(mgref , " message. number_rcvd") + 1; 
call alter_(mgref , "message. number _revd", rev_msg_numb) ; 
call write_list ("Process ", accept_proc_name , " at node ", 

accept node_name, "has been awakened upon"); 
call write_list_J" receipt of a message in message group", 

mg_name) ? 
end: 
return: 



/• PROCESS OBPL PASS 6/24/76 •/ 

process_obpl_pass: entry (p_obpl_passref ) ; 

/* This procedure will allow a partially expanded OBPL to be "received" by a 

node and then be expanded as much as possible within that node */ 
/* Get the location of the OBPL entity that has been "passed" between nodes. 

We need not check "eos" because we know the desired entity exists. */ 
call find_first_(obplref , "obpl_pass->obpl", p_obpl_passref . eos): 
/* Get the name of the node receiving the control message. */ 
rev node_name = extract_(p obpl_passref, "0bpl_pass.de3t_n0de_.name"); 
/• Remove the OBPL from this control message so that we can send the expanded 

OBPL in another control message if necessary */ 
call remove_(obplref , "obpl_pass->obpl") ; 

/* Expand the OBPL as much as possible in the receiving node */ 
call exp_obpl(obplref, rcv_node_name) ; 
return: 
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/* PROCESS RESOURCE GRANT 6/15/76 V 

proeess_res_grant : entry( p_res_grantref ) ; 

/■ This procedure will wake up a process and give it access to a resource as 
specified by the remote resource grant control message pointed to by 
w p res_grantref" •/ 
/• Get the names of the prooess, resource and nodes involved */ 
process name r extraot_(p rea_grantref , "res_grant.proc_name"): 
proc_node_name = extraot_Tp_res_grantref, "res_grant.proo_node_.name"); 
dbo_name = extract (p_res_grantref, "res_grant.res_name"); 
dbo node name s extract _(p res_grantref,^res_grant.res_j3ode_name"); 
/■ Find the locations or the entities for the prooess, resource and their node 
tables within the node specified by "proc_node name". Note that we need 
not test "eos" because we know the names placed* in the control message 
represent existing entities. •/ 
eos = find entity_loc(proc_.noderef, "sys->node" , SYS REF, proc node name, 
"node. name"); _ _ , 

eos = find_entity loo (proc tableref. "node->node_table" , proe_noderef , 

proc _node_name, "nodetable.name"); 
eos = find entlty_loe( procref, "node-process 11 , proc tableref, process name, 

"process. name"); 
eos = findentity_loc( dbo tableref. "node->node_table" , proe_noderef , 

dbo node_name . *node table . name" ) ; 
eos = find entity_Ioc(dboref, "node->dbo" , dbo_tableref , dbo_name, 

"dbo. name"): 
/* Unblock the process */ 
call remove_(procref, "node/dbo/mg->process" ) ; 

call insert_(procref, "node/dbo/mg->process" , "first", proc tableref); 
/• Give the process exclusive or shared access to the dbo, depending upon the 

type of access that was requested. */ 
if extract (procref, "prooess. aeeess_type") s "exclusive" 
then do; 

/• Grant the process exolusive control of the database object •/ 
call insert (dboref, "process->dbo" , "first", procref); 
call write list (prooess_name, "at node", proc_node_name , 

w has been granted exclusive use of"); 
call write_list_(" ", dbo_name, "at node", dbo_node name); 
return; 
end; 
else do; 

/• Grant the process shared access to the database object */ 
call dcl_dbo sh_asmt(sh_asmtref); 

call insert_Tsh_asmtref, "dbo->dbo_ sh„asmt", "first", dboref); 
call insert (sh_asmtref, "process-Tdbo_sh_asmt", "first", procref); 
call write list (process_name. "at node", proc_node_name , 

"has been granted shared access to"); 
call write_list_(" ", dbo_name, "at node", dbo_node name); 
return; 
end; 
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/• PROCESS RESOURCE RELEASE 6/15/76 •/ 

process_res_rel : entry ( p_res_relref) ; 

/• This procedure will release a resource from control by a remote process, 
as specified in the resource release control message. If possible, 
additional processes will be removed /mm the queue for the database 
object and will be granted access to the database object */ 

/* Get the names of the process, resource and nodes involved */ 

process_name = extract^ preaLrelref , "rfts^^l.f^l^fwrocLjsame"); 

proc_node_name s extracfc^TR^rearelref , ^s* i re§»f>al v jNBode name"); 

dbo_name s extract—Cp^rejBrelref, "res^el*a^t - jifeo.jM*e"); 

t •(¥ rea_.relref, "raa_j?el»d#a|^«©de_nj 



dbo node_name = exTraet~Ip ras__relraf, "rea_j?ai»d«i|^«ode_name"); 
/• Tind the locations of the entities for the ©recess, resource and their 
node tables within the node specified by ^^fce^BodejDame" . Mote that we 
do not test "eos" because we know the -samea pifoad la the resource release 
trol message represent existing entities. ,*/ 
find_entlty_loefdho,_nodoref, "sys->node* f SYS_RBF, dbo_node_name , 



control 
eos _ 

^node.hame* ,, 
eos = find entity_loe{eb© tableref, "node->node_table" , dbo_noderef, 

Hbo node name, *node_table*name"); 
eos = find_entity_Toc( dboref, "node->dbo" , dbo_tableref , dbo_name, 

"dbo. name"): 
eos = find_entity_loc(proc i tableref t "node->node_table" , dbo_noderef, 

proc node_naae, "nodetable.naae"); 
eos = find_entity_loc(|3irocref , "node^^roeaas*,, «roq__tableref , 

process name, "ppooess.naae"): 
call write_list_(dbo_Daae, "at node", dbo_node_name, "has been released by"); 
call write list_(" ", process_name , "at node*, proc_node_name) ; 
/• Check if the process had exclusive oontrol of the database object •/ 
if inserted_(dboref, *pf»o«as-Mbo" ) 
then do; 

/• Release the database object and t^nan grant at least one other 
process access to the database object if any processes are 
queued for it */ 
call remove (dboref, "process-Mbo"); 
if empty_(dboref, "node/dbo/ag->pro©ess" ) 

then call rem_proc_froffl_qMaue(dboref, dbo_tableref ) ; 
return; 
end ; 
else do; 

/* Release the database object from this shared assignment, and if 
there are no other processes currently having shared access to 
the database object we can grant another process access to the 
database object if any are queued for it ■•/ 
call find_first_intersection_(sh_asmtref, "process- >dbo_sh_asmt", 

procref, "dbo->dbCLJih_aamt* f dboref, eos); 
call delete_entity_(shasmtref, "dbcushjaamt" ) ; 
if member_count_( dboref, "dbo->dbo_st[jeamt") * 

then if empty_( dboref, "node7dbo/mg->process" ) 

then call rem_proc_from_queue( dboref , dbo_tableref ) ; 
return ; 
end; 
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/« PROCESS RESOURCE REQUEST 6/15/76 •/ 

prooess_rea_req : entry(p_res_reqref ) ; 

/* This procedure will prooess a request for a resource from a remote 
process, as specified in the resource request control message. If 
the resource can be assigned, it will be and a control message will 
be generated to that effect. Otherwise the process will remain blocked 
until the resource becomes available. */ 

/• Get the names of the process, resource and nodes involved •/ 

process name s extract_(p rea_reqref f " 

proc_noae_name = extract_Tp_res re< 



qref, "res_req.req_j>roc name"): 
reqref , "res_req • req_node name" ) ; 
, "r es_req . d est_dbo name "T; 



dbo_name = extract (p_res_reqref\ _. _,, _ . , 

dbo node name s extract (pres__reqref, "res_req.dest_node_hame"); 

/* Find the locations or the entities for the process, resource and their 
respective node tables within the node specified by "dbo_node_name". If 
the node is unaware of the existence of the process, create a local entity 
for that process, e do not have to test eos because we know the entities 
for the node tables and the resource exist because the names were placed 
in the resource request control message */ 

eos = find entity_locCdbo_noderef, "sys->node", SYS_REF, dbo_node_name, 
node ncunG* ) * 

eos = find entity_locUbo tableref . "node->node_table" , dbo_noderef, 
dbo_node name, "node table . name" ) ; 

eos = find entity_Toe( dboref, "node->dbo", dbo_tableref , dbo_name, 
"dbo. name"): 

eos = find_entity loetproc tableref. "node->node_table" , dbo_noderef, 

?roc_noae name , "node table . name" ) ; 
_ ity_loc(procref, "node->process" , proc_tableref , process_name, 
"prooess. name") 
then do; 

/• Create a "local" entity for the process, since one does not 

already exist */ 
call dcl_process(procref , process_name) : 

call inaert_( procref , "node->process" , "first", proc tableref); 
call inaert_(procref, "node/dbo/mg->process" , "first 15 ", 

proc_tableref ) ; 
end: 
/* Determine what type of access is desired •/ 
access_type = extract_(p_res_reqref , "res_req.aceess_type"); 
/* Check if the database object might be available for assignment */ 
if inserted_(dboref , "process->dbo") ! empty_(dboref , "node/dbo/mg->process") 
then do; /*Block the process if the database object has been 
assigned to another process for exclusive use or 
if other processes are currently queued for the 
database object */ 
call alter_( procref, "process. access_type", access_type) ; 
call remove! procref, "node/dbo/mg->process" ) ; 
call insert (procref, "node/dbo/mg->process" , "last", dboref): 
call write_list ("Resource not available, process remains blocked"); 
call initiate_oDpl(proc_node_name, process_name , dbo_node_name , 

dbo_name, "dbo"); 
return; 
end: 
/* Check if the request is for shared access */ 
if aecess_type = "shared" 

then do; /*Give the process shared access to the desired 
database object •/ 
call del_dbo sh_asmt ( sh_asmtref ) ; 

call insert_Tsh_asmtref, "dbo->dbo sh_asmt", "first", dboref); 
call insert (sh_asmtref, "process->dbo_sh_asmt", "first", procref): 
call write Tist_(process_name, "at node", proc_node_name , 

"is granted shared access to"): 
call write_list_(" ", dbo_name, "at node", dbo_node_name) : 
call dcl w rem_res_j5rant(dbo_node_name, dbo_name, proc_node_name , 

processname, cont_msg_numb) ; 
call write list_( "Control message number", cont_msg_^numb, 

"sent from", dbo_node_name. "to", proc_noae_name ) ; 
call write_list_(" representing this allocation"): 
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return; 
end; 
/•The next if statement will be executed if the request is for 

exclusive use of the database object •/ 
/• Check if any process has shared access to the desired database object */ 
if empty (dboref, "dbo->dbo_sh_asmt") 

then Ho; /*Queue the process for exclusive use of the database 
object because at least one other process currently 
has shared access to the database object. */ 
call alter_(proeref , "process. aecess_type" , "exclusive"); 
call removetprocref , "node/dbo/mg->prooess" ) ; 
call insert_(procref , "node/dbo/mg->process" , "last", dboref); 
call write Tist_( "Resource is not currently available for", 

"exclusive use, process", process_naae) ; 
call write list (" at node", proc_node_name , 

"remains blocked"); 
call initiate_obpl(proc_node_name, process_name, dbo_node_name, 

dbouname, "dbo"); 
return ; 
end; 
else do; /*Grant the process exclusive use of the desired 
d&£&.b&s6 od 1gc£> ^ / 
call insert (dboref, "process->dbo" , "first", procref); 
call write Tist_(process_name, "at node", proc_node_naae, 

"is granted exclusive use of"): 
call write_list_(" ", dbo_name, "at node", dbo_node_name) : 
call dcl_rem_res_grant(dbo_node_name, dbo_name, proc_node_name, 

process name, cont_msg_numD) ; 
call write list^(""Control message number", cont_msg_nuab , 

"sent from", dbo_node_naae, "to", proc_node_name); 
call write_list_(" representing this allocation"); 
return : 
end; 
end RCV_CM; 
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Procedure OBPL 



OBPL: procedure; 

.... /* This procedure is a collection of subroutines which act on 
an OBPL and check for deadlock. 
The following support routines are included: 

CHECK FOR DEADLOCK 

COPY OBPL 

EXPAND OBPL 

OBPL ADD RESOURCE •/ 
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CHECK FOR DEADLOCK 6/25/76 




. P__ _ _ 
entry in the OBPL pointed to by l, p_obplref . If no such entry exists, 
then one will be created and "p eos" will be set to "1"b, indicating that 
there is no deadlock. If an entry already exists for the process, we 
have a deadlock and a message will be printed giving the processes 
involved and "p_eos" will be set to "0"b indicating a deadlock has been 
detected. */ 
/* Get the location of the first proo_entry in the OBPL */ 
call find_first_(proc_entryref, M obpl->proc entry", p_obplref. p_eos) : 
/* For each proc_entry in the OBPL, check iT it matches the given process. 
Note that if we detect a deadlock, we will return from inside the loop 
and p_eos will be 0. If no deadlock is detected we will exit the loop 
before returning and p_eos will be 1, as desired. */ 
do while ( p_eos); 

/* If we have a match with "p_process_name" and a proc_entry, we must 

then check if the node name attribute matches "p_proc_node_name" */ 
if p_proces3_name = extract__(proe_entryref, "proc_entry.process_name") 
then if p_proc_node_name = extract__(proc_entryref, 
"proe_entry.node_name") 
then do; 

/* A deadlock has been detected, list all the processes 

involved and return. •/ 
call write list ("A deadlock has been detected.", 

"The following processes are involved:"); 
eos = "0"bi 
do while ( eos) ; 

process_name = extraet_(proc_entryref, 

"PPOCL-entry . process__name" ) ; 
proc_node_name = extract_(proc_entryref, 

"proc_entry . node_name" ) ; 
call write list_(" ", process_name, 

"at node ", proc_node_nameJ; 
call find_prior_(proc_entryref , "obpl->proc_entry" , 

eos); 
end: 
call write_list_( n End of deadlock list"): 
return; 
end; 
/* Get the next proc_entry in the OBPL •/ 
call find_next_(proc_entryref , "obpl->proc_entry", p_eos): 
end: 
/* No deadlock has been detected, so create a new proe_entry and have it 

inserted into the OBPL */ 
call dcl_proc_entry(p_obplref , p_proc_node_name , p_process_name) : 
return: 
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/• COPY OBPL 6/25/76 V 

copy obpl: entry (peopyref, p_obplref ) : 

/• This procedure will copy the OBPL pointed to by n p_obplref" and return 
a pointer to the copy via "p_copyref". The order of the OBPL entries, 
and their attribute values in the copy will be identical to those in 
the original. */ 
/• Get the attribute values (resource information) from the OBPL entity 

pointed to by "p obplref". •/ 
res_name = extract_Tp_obplref , "obpl. res name"); 
res_node_name = extract Tp_obplref, "obpT.res node_name"); 
i*es_type = extract_(p obplref , "obpl.res_type ir ); 
/* Create an OBPL entity with the above attribute values */ 
call dcl_obpl(p_eopyref. res_node_name , res_name, res_type): 
message numb = extract_(p obplref , "obpl.msg_numb"): 
call alter_(p_eopyref, "obpl.msg_numb" message_numb) ; 
/• Get the last entry in the OBPL pointed to by n p_obplref" •/ 
call find_last (old_p roc entry ref, w obpl->proc_entry n , p obplref, eos): 
/» Copy eajh OBPL entry T / 
do while ( eos) ; 

/• Get the attribute values of the proc_entry pointed to by 

"old_proe_entryref" */ 
process name = extract_(old_proc_entryref f "proc_entry.process_name ,, ); 
proc_noae_name = extract_(old oroc_entryref, n proc_entry.node name"): 
/• Create a new proc_entry with the above attribute values and" 

insert it into the new copy of the OBPL. */ 
call dclproc_entry(p_copyref, proe_node_name, process_name); 
/■ See if there are any more proc entries to be copied */ 
call find_prior_(old_proc_entryre7, "obpl->proc_entry" , eos); 
end: 
return : 
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/• EXPAND OBPL % 6/2H/76 •/ 

exp obpl: entry (p_obplref, p_rcv_node_name) ; 

/• This procedure will expand the OBPL pointed to by "p_obplref". It will 
be expanded as much as poxxible using the Information available to the 
node speoified by "p rov_node name" */ 
/• Get the fully qualified name (resource name plus the name of the node 
in which it resides) of the resource which is controlled by or being 
waited for by the last process to be added to the OBPL. (Note that we 
add processes to the OBPL by inserting them at the beginning of the set */ 
res_name = extract (p_obplref, "obpl.resname"); 
res_node_name = extract_(p_obplref , n obpT.res_node name"); 
/* Get the type of the resource ("message" or "dbo" or "op_msg") */ 
res_type = extract_(p_obplref , "obpl.res__type"); 
if res_type = "message" 
then do* 

/* The resource type is a message, therefore we know the process 
that can send the desired message is in the node that is 
expanding the OBPL. We will act accordingly. ■/ 
/• Get the location of the entity for the message group from which 
a message is desired. We need not test "eos" because we know 
the entity exists. */ 
eos = find entity_loc(mgref, "sys->message", SYS_REF, res_name, 

••message . name" ) : 
/• Get the number (within the message group) of the message 

that is desired. */ 
message numb = extract_(p_obplref , "obpl.msg_numb"); 
/• If this number is less than or equal to the number of messages 

jent in this message group, then there is no deadlock. */ 
if (message_numb > extract_(mgref, "message. number_sent" ) ) 

then return; 
/• Find the process that can send the desired message •/ 
call find_owner (procref, "send-proc-^raessage", mgref); 
/* Find out if the process is active. (If it Is active there 

is no deadlock.) •/ 
call find_owner_(ndm_proc_ownerref , "node/dbo/mg->process" , 

procref) ; 
if entity_class_name_(ndm_proc_ownerref) » "node_table" 

then return; 
/* Get the process name and check for deadlock */ 
process_name = extract (procref, "process.name"); 
call check_for_deadlock(p_obplref , res_node_name , proeess_name , 

eos); 
/• If eos a then a deadlock has been detected and we are done •/ 
if Ceos) 

then return; 
/• Add the resource that the process is waiting for to the OBPL •/ 
call obpl_add_resource(p_obplref , ndm_proc_ownerref , 

p_rcv node name, eos); 
/•If eos = 1 then the resource the process is waiting for is in 
the same node as the process, so we can continue to expand 
the OBPL. •/ 
if eos 

then call exp_obpl(p_obplref , p_rcy_node_name) ; 
return: 
end; 
if res_type = "op_msg" 
then do: 

/• The resource type is an operator message, therefore we know 
the last process to be added to the OBPL is waiting for a 
message from an operator at the same node. We will act 
accordingly. •/ 
/* Get the location of the entity for the operator connection 

over which a message is desired */ 
eos = find_entity_loc(op_conref, "sys->op_con" , SYS_REF, 

res_name , "op_con .name" ) ; 
/* Get the location and name of the operator who can send the 
desired message */ 
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call find_owner_(opref. "operator->op_oon" , op conref); 
operator_name s extract_(opref, "operator. name*): 
/■ Check if the operator is already in the OBPL list «/ 
call eheok_for_deadlock(p_obplref , res_node_name , 

operator_name , eos) ; 
/• If eos = then a deadlock has been detected and we are done */ 
if ( eos) 

then return: 
/* Queue the OBPL and request status information from the 

operator •/ 
call insert (pobplref, "operator->obpl", "first", opref ) ; 
call write list_( "An OBPL has been queued waiting for a status", 

"report from operator", operator_name) ; 
call write list (" at node", res node_name, 

"The Involved operator connection is", res_name): 
return: 
end; 
/* If the next section is executed, a database object is controlled by or 

is being waited for by the last process to be added to the OBPL */ 
/• Get the name and location of the last process to be added to the OBPL */ 
call find_first_(obpl w procref, "obpl->proe_entry" , p_obplref, eos); 
obpl_proc_name = extract (obplprooref, "proc entry. process_name"): 
obpl_proc_node name = extract_Tobpl_proeref , ir proc_entry.node_name") : 
/* Get the entity locations for the database object and its node table, and 
the process and its node table within the node specified by 
"p_rcv_node_name". We need not test "eos" in most cases because we 
know the entities exist */ 
eos r find, entity_loc(rev_noderef, "sys->node", SYS_REF, p_rcv_node_name , 

"node.name"); 
eos = find_entity_loc(obpl proc_node_tableref, "node->node_table" , 

rcv_noderef, obpX_proc_node_name , "node_table.naae"); 
eos s find_entity_loo(res node_tableref, "node->node_table" , rcv_noderef, 

res node name, "node_table.name"); 
eos = find_entity_Toc(obplprocref, "node->process" , obpl_proc_node_tableref , 

obpl_proe_name, "process. name"); 
/• We must test "eos" to see if the node containing the resource is aware 
of the existence of the most recently inserted process in the OBPL. If 
it is not, we have no deadlock at this time, so we can return */ 
if eos 

then return: 
eos = find_entity_loc(resref , "node->dbo", res_node_tableref , 

res name, "dbo.name"): 
/* Check if the resource is in the node that is expanding the OBPL */ 
if res node_name = p_rcv_node_name 
then do; 

/* Verify that the process specified by "obpl_proc name" is still 

waiting for the resource specified by "res name 1 * •/ 
call find_owner_(ndm_proc_ownerref , "node/dbo7mg->process" , 

obpl_procref ) ; 
if resref = ndm_proe_ownerref 

then return: 
/* We must now add an entry to the OBPL for the process 
that controls the resource specified by "res_name", 

grovided that the process is not already in the 
BPL. If there are n processes that have shared 
access to the database object, then we must create 
n copies of the OBPL and use a different copy 
for each reader •/ 
if insert ed_( resref , "process->dbo") 
then do; 

/■ The database objeot is held for exclusive 
use. Find the controlling process and 
check for deadlock. •/ 
call find_owner (prooref, "process->dbo" , 

resref) ; 
process_name = extract_(procref , "process. name"): 
call find_owner_(proc_tabieref , "node->process" , 
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prooref ) ; 
proc_node_name s extraot_(proe_tableref, 

"node_table . name" ) ; 
call find_owner (ndm_proo_ownerref, 

"node7dbo/mg->process", procref); 
/•If the process is active and it is at the 
same node as the resource, then we have 
no deadlock. ■/ 
if entity_class_name (ndm_proc_ownerref) 

= "node_table" & proc_node_name 
= res_node_name 
then return; 
call check_for__deadloek(p_obplref , 

proc_node_name , process_name, eos); 
/•If eos s 0, than a deadlock has been 

detected and we are done •/ 
if (eos) 

then return; 
if proc_node_name s res_node_name 
then do; 

/• The process is in the same node as 
the database object, so we can 
continue to expand the OBPL •/ 
/• Add to the OBPL the resource that the process 

is waiting for •/ 
call obpl_adcLresource(p_obplref, 
ndBLproc ownerref, 
p_rev node name , eos ) ; 
/•If eos s 1 , then the resource that was added 
to the OBPL is in the same node as the 
process that is waiting for it, so we can 
further expand the OBPL •/ 
if eos 

then call exp_obpl(p_obplref , 
P_rcv_node_name) : 
return; 
end; 
else do: 

/• Send the OBPL to the node specified 

by "proc_node_name" */ 
call dcl_obpl_cont_msg(p_obplref , 

proc_node_name , p_rcv_node_name ) ; 
return; 
end; 
end; 
/• If the following code is executed, the database object 
has n readers. We need to make n-1 additional copies 
of the OBPL. Bach time we make a copy of the OBPL, 
we expand that copy as much as possible for the given 
node and the process that we are associating with 
this copy •/ 
/• Find a process that has shared access to the 

database object •/ 
call find_first (sh_asmtref, "dbo->dbo_sh_asmt", 

resrer. eos) ; 
call find_owner_(first_procref, "process->dbo_sh_asmt", 

sh asmtref ) ; 
/• We will check for deadlock Involving the OBPL and the 
process pointed to by "first orooref" after we check 
for deadlock with all the otner readers of the 
database object. We will teherefore use the "original" 
OBPL (rather than a copy) for this check •/ 
call find next (sh_asmtref, "dbo->dbo_sh_asmt", eos); 
do while T eosT: 

/• Find the process that has the shared access 
represented by the dbo sh_asmt entity pointed 
to by "sh_asmtref" •/ 
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call find_owner_(procref, "process->dbo_sh_asrat", 

sh_asmtref ) ; 
process_name = extract_(procref , "process. name" ) ; 
/• Get the name of the node in which the process 

resides */ 
call find_owner_(proc_tableref , H node->process", 

procref ) ; 
proc_node_name = extract_(proc_tableref , 

"node_table . name" ) ; 
/• If the process is not active or if it is at a node 
different from the node in which the resource 
resides, then we must check for deadlock. •/ 
call find_owner (ndm_proc_ownerref, 

"node/dbo/mg->proeess", procref): 
if entity_glass_name_(ndm_proc_ownerref) 

„* w node_table" J (proc_node_name 
= res_node_name) 
then do; 

/* Copy the OBPL and check for deadlock •/ 
call copy obpl( new obplref , p obplref); 
call eheck_for_deadloek(new_obplref , 

proc node_name, process_name. eos): 
/• If eos = 1 then we must either continue 
to expand the list or send it to 
another node */ 
if eos 

then if proc_node_name = res_node_name 
then do; 

/* Add to the OBPL the resource that 

the process is waiting for */ 
call obpl_add_resource( 
new_obplref , 
ndm_proc_ownerref , 
p_rcv_node_name , eos); 
/* If eos = 1. then the resource that 
was added to the OBPL is in the 
same node as the process that is 
waiting for it. so we can further 
expand the OBPL ■/ 
if eos 

then call exp_obpl( 

new_obplref , 
p_rcv_node_name) : 
end: 
else call dcl_obpl_cont_msg( 
new_obplref, 
proe_node_name , 
p_rcv_node_name) ; 
end; 
/* See if there are any more readers of the database 

object specified by "resjname" •/ 
call find_next_(sh_asmtref , "dbo->dbo_sh_asmt", eos); 
end: 
/* Find the process name and the node in which it resides 

for the process pointed to by "first_procref" •/ 
process_name = extract (firstprocref, "process. name"): 
call find_owner_(proc_tablerer, "node->process", 

f irst_procref ) : 
proc node_name = extract_(proc_tableref , "node_table.name") : 
/* If the process is at the same node as the resource and 

it is active, we need not check for deadlock. */ 
call find_owner_(ndm_proc_ownerref , "node/dbo/mg->process" , 

f irst_procref ) : 
if entity_class_name_(ndm_proc_ownerref) = "node_table" 
& proc.node^name = res_node_name 
then return; 
/* Cheek for deadlock and then expand the OBPL or send 
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it to another node */ 
call check_for_deadlock(p_obplref , proc_node_name , 

process_name, eos); 
if eos 

then if proc_node_name * res_node_name 
then do; 

call obpl_add_resouree( p_obplref , 

ndm proe_ownerref , p_rcv_node_name , 
eosT; 
if eos 

then call exp_obpl(p_obplref , 
p_rcv_node_rtame) ; 
end: 
else call dcl_obpl l _cont_msg(p_obplref , 

proc_node_name , p_rev_node_name ) ; 
return; 
end: 
/• The next section of code will be executed if the resource is located 

in a node different from the one that is expanding the list */ 
/• First check if the process is active. If it is active, we are done */ 
call find_owner_(ndBL.proc_ownerref, w node/dbo/mg->process" , obpl_procref ) : 
if entity_class_name_indnL.proc_ownerref) « "node__table n 

then return: 
/* Verify that the process specified by n obpl_proc_name" still controls 

the resource specified by "res_name w */ 
/• See if the process had either exolusive or shared access to 

the database object specified by B res_narae". If it has neither, 
we can return. •/ 
if (empty_intersection (obpl_proeref, "process->dbo" , res_node_tableref , 
"node->dbo ,, )T 4 {empty_interseotion_(obp2 l _j>rocref , 
w process~>dbo_sh_asmt" , resref, B dbo->dbo_sh_asmt")) 
t hen p©tupn * 
/• Add to the OBPL the resource that the process is waiting for •/ 
call obpl_add_resource(p_obplref, ndm_proc_ownerref. p_rcv_node name, eos): 
/* If eos = 1 , then the resource that was added to the OBPL is in the same 
node as the process that is waiting for it, so we can further expand 
the OBPL */ 
if eos 

then call exp_obpl(p_obplref , p_rcv_node_name) ; 
return: 
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/• OBPL ADD RESOURCE 6/24/76 •/ 

obpl_add_resource: entry (p_obplref , p_ndm_proc_ownerref , p_rcv_node_name , 

p_eoa ) ; 
/* This procedure will be passed a pointer to a resource that the most 

recently inserted process in an OBPL is waiting for. The prooedure will 
determine the type of resource that "p_ndm_proc_ownerref" points to, and 
will insert information about this resource into the OBPL entity pointed 
to by "p_obplref " . If the resource is in the node specified by 
"p_rcv_node_name", then p_eos will be set to 1, otherwise it will be set 
to and the OBPL will be sent to the node that contains the resource •/ 
if entity_class_name_(p_ndm_proc_ownerref) = "dbo" 
then do; 

/• Get the database object name and get the name of the node in 

which it resides •/ 
res name = extraet_(p_jidm_proc_ownerref , "dbo. name"); 
call find_owner_(res_node3ableref , "node->dbo" , 

p_ndm_proc_ownerref ) ; 
res node_name = extract (res_node tableref, "node_table.narae"); 
call alter_(p_obplref , "obpl.res_type", "dbo"); 
end; 
if entity_class_name_(p_ndm_proc_ownerref) = "message" 
then do; 

/* Get the message group name and the name of the node from 

which a message should be coming */ 
res name = extract_(p_ndm_proc_ownerref , "message. name"); 
call find_owner_(res_node3ableref, "init_node->message" , 

p_ndm_proc_ownerref ) ; 
res node name = extract_(res_node tableref, "node_table.name"); 
/* Get the number of the message Twithin the message group) that 

is desired and insert this into the OBPL */ 
message numb = extract_(p ndm_proe_ownerref, "message. number_qd")+1; 
call alter_(p_obplref , "obpl.msg_numb", message_numb) ; 
call alter_(p_obplref , "obpl.res_type w , "message"); 
end; 
if entity_class_name_(p_ndm_proc_ownerref) = "Op_con" 
then do; 

/* Get the name of the operator connection over which a message 

from an operator is desired •/ 
res name = extraet_(p_ndm_proc_ownerref , "op_con.name"): 
/* The resource (operator connection) is located entirely in 
one node, so the resource node name is the same as that of 
the node processing the OBPL *7 
res node_name = p rcv_node_name; 
call alter_(p_obpiref , "obpl.res_type", "op_msg"); 
end; 
/• Put the resource name and its node name into the OBPL */ 
call alter_Jp_obplref, "obpl.res_name", res_name); 
call alter (pobplref, "obpl.res_node_name", res node_name): 
/• Check if the node can continue to expand the 0~BPL or if it must send the 

OBPL to another node */ 
if res_node_name = p rcv_node_name 
then p_eos = "I'd: 
else do; 

p_eos = "0"b: 

call del_obpl_cont_msg(p_obplref , res_node_name , p_rcv_node_name) ; 
return: 
end OBPL: 
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Procedure REL 



REL: procedure: 

/* This procedure contains subroutines which allow processes 
to release resources and then assigns the released resource to a new 
process if possible. The following user visible function is Included: 

RELEASE DATABASE OBJECT 
The following support routine is included: 

REMOVE PROCESS FROM QUEUE •/ 



del cont_msg_numb 

del dbo_name 

del dbo_node_name 

del dboref 

del dbo_tableref 

del eos 

del ndm_proc_ownerref 

del ownerref 

del p_dbo_name 

del p_dbo_jnode_name 

del p_dboref 

del p_dbo_tableref 

del pnoderef 

del p_process name 

del p_proc_noae_name 

del process name 

del proc_node_name 

del proeref 

del ptableref 

del res_rel_ref 

del see_node_name 

del sh_asmtref 

del tableref 

del temp_name 

del wrifce_list_ 

^include DDM_serv routines; 

t include ADT_primTtives ; 



fixed bin; 

char(12); 

char(12): % 

fixed bin(17); 

fixed bin(l7); 

bit(1); / % 

fixed bin(17); 

fixed bin (17); 

char(*); 

char( # ): 

fixed bin(17 

fixed bln(17 

fixed bin(17 

char( 

char( 

ehar(12; 

char(12) , 

fixed bin(17); 

fixed bin(17); 

fixed bin(17); 

char(12); 

fixed bin(17); 

fixed bin(17); 

char(12): 

entry options (variable); 
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/* RELEASE DATABASE OBJECT 6/2/76 •/ 

release_dbo: rldbo: entry(p_proc_node_name, p_proeess_name , p_dbo_node_name , 

p_dbo__name): 
/• This procedure will cause the process specified by "p Drocess name" (at 
node "p_proc_node name") to release its control over The dataDase object 
specified by "p_dbo name" and located at the node specified by 
n p_dbo_node_name" *7 
/* Verify that the node specified by w p jproc node_name" exists •/ 
if find_entity_loc(pnoderef , "sys->node", SYS~_REF, p_proc_node_name , 
"node. name"); 
then do: 

call write list_( "Invalid process node name. ", p_proc_node_narae , 

"does not exist"); 
return; 
end: 
/* Verify that the process specified by "p_process_name" exists at the node 

specified by "p broc node_name" •/ 
eos = find_entlty_Toc(ptableref , "node->node table", pnoderef, 

p _proc_node_name , "node table. name"): 
if find_entity_loc( procref , "node-->process" , ptableref, p_process_name, 
"process . name " ) 
then do: 

call write_list_(" Invalid process name.", p Drocess_name, "at node", 

p_proe_node_name , "does not exist 1 ';; 
return; 
end: 
/• Verify that the node specified by "pdbo_node name" exists */ 
if find_entity_loc(dbo_tableref, "node->node table", pnoderef, 
p_dbo_node_name , "node_table . name"; 
then do: 

call write_list_( "Invalid database object node name. ", 

p_dbo_node_name, "does not exist."); 
return; 
end: 
/* Verify that the database object specified by "p_dbo_name" exists at the 
node specified by "p_dbo_jnode__name" and that the process specified by 
"p_process_name" has access to it. •/ 
/• Verify that the node containing the process is aware of the existence of 

the database object ■/ 
if find_entity_loc(dboref , "node->dbo", dbo_tableref , p_dbo_name, "dbo.name") 
then do: 

call write list_("Invalid release. Process", p process_name, 

"at node", p_proc_node_name , "does not have"); 
call write_list_(" access to", p_dbo_name, "at node", 

P_dbo_node_naroe) ; 
return; 
end: 
/• Verify that the process has access to the database object •/ 
if find_entity_loc(dboref, "process->dbo", procref. p_dbo_name, "dbo.name") 
4 empty intersection_( procref , "process->dbo_sh_asmt", dboref, 
"dbo->dbo_sh_asmt" ) 
then do; 

call write list_( "Invalid release. Process", p_process_name , 

"at node", p_proc_node_name , "does not have"); 
call write_list_(" access to", p_dbo_name, "at node", 

P_dbo_node_name) ; 
return; 
end; 
/* Verify that the process is active */ 

call find_owner_(ndm_proc_ownerref, "node/dbo/mg->process", procref); 
if entity_class_name_(ndm_proc_ownerref) *= "node_table" 
then do; 

call write list_( "Invalid release. Process ". p_process_name , 

"at node", p_proc_node_name , "is not active"); 
return; 
end; 
/* Check if the database object is at a node different from the one that 
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contains the procgss */ 
if p_proc_node_name = p_dbo_node_name 
then do: 

/* Release the resource and send a resource release control message 

to the node which contains the database object */ 
/* Check if there are no more "local" processes queued for the 

specified remote database object */ 
if empty_(dboref , "node/dbo/mg*->proces3") 
then do; 

/• If the process had exclusive control of the database 
object or if no other local process had shared access 
to the database object, then we can delete all local 
information about the remote database object, 
otherwise just "release" the shared access of the 

Erocess to the database object */ 
nserted_(dboref , "proceas->dbo" ) 

| member_eount (dboref, "dbo->dbo_sh_asmt") < 2 
then call delete_entity_( dboref , "dbo"T; 
cXsg do " 

/•'Find the entity for the involved dbo_sh_asmt 

and delete it */ 
call f ind_f irst_J.ntersection_( sh_asmtref , 
"process->dbo_sh_asmt", procref. 
"dbo-Mbo.sh^asmt" , dboref, eos); 
call delete_entity_Tsh_aamtref , "dbo_sh_asmt"); 
end; 
end; 
else do; 

/* Release the database object from access by the process, 
but retain other local information about the remote 
database object */ 
if inserted_( dboref , "process~>dbo" ) 

then call remove_i dboref, "process->dbo" ) ; 
else do: 

call f ind_f irst_intersection_( sh_asmtref , 
"process->dbo_sh_asmt", procref. 
"dbe->dbo_sh_asmt", dboref, eos); 
call delete_entity_(sh_asmtref , "dbo_sh_asmt"); 
end: 
end; 
/• Create an entity for a remote resource release and the declare it 

as a control message •/ 
call create_entity_(res_rel_ref , "res_j*el"): 
call create attribute_(res_rel_ref, "res_rel.rel_pnode_name", 

"field, 12, b_proc_node name); 
call ereate_attribute_Jres_rel_ref , "res_rel.rel_proc_name", 

"field", 12, p_process_name) ; 
call create attribute_(res rel_ref, "res_rel.dest_node_name", 



"7ield", 12, p_d¥o_node _name)f 
;e attribute_(res rel_ref, 



call create attribute_(res_rel_ref, "res_rel.dest_dbo_name", 

"field", 12, p dbo_name); 
call dcl_control_messageTres_re] w ref , "res_rel", cont_msg_numb): 
call insert (res rel_ref. "sys->control_message", "last"7 SYS_REF); 
call write Tist_T"Control message number", cont_msg_numb , 

'"'sent from", p_proc_node_name , "to", p_dbo_node_name) ; 
call write_list_(" representing a remote resource release"); 
return; 
end: 
/* The next section will be executed if the process and database object are 

located in the same node •/ 
/• Check if the process had exclusive control of the database object •/ 
if i nserted_( dboref , "process->dbo") 
then do; 

/* Release the database object and then grant at least one other 
process access to the database object if any processes are 

?ueued for it. */ 
remove_( dboref, "process->dbo"); 
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call write_JJ.st_( "Process", p r>rooes8__nsmc . "at node", 
11 4 t P«Pi*o«L§o4eLnajie, B Bas released database"); 
call Wite -^JJ-A* d object", p_dbo_name, "at node", 

if ~ empty Jflboref , %ode/dbo/ag~>process*) 

then osll re^_proc_froni_queue{dboref , dbo_tableref ) ; 
return ; 
end; 
else do; 

/* Release the database object from this shared assignment, and if 
there are no other processes currently having shared access to 
the database object we can grant another process access to the 

call find_first^tereection_(eh_aeatre/, »prooess f ->dbo_sh_asmt\ 

call ^ite_list_(*Frocess ¥ , Deroeese^naae, "et node", 

M ii ^itfiEPilP*-*"" 9 Slw iitabase") ; 
call ¥rlfce -*I^J*^ ; ,©b3«&t", "a^bejtaae, fat node", 

if "•■berjwjo^ * 

then if eaptv (dborsf, "node7dbo/ag->prooes8" ) 
then oall re«_proc_fro*_queue<dboref, dbo_t 



return: 
end; 



_tableref ) ; 



/* REMOVE PROCESS FROM QUEUE 6/3/76 */ 

r^jroc_f rear queue: . ,«P#ytPudboref , p_dbo_tableref) ; 

' S^«P r ??? u r e "H 1 **•"$ t l l**li onerfboaaa access to the database 
object that is referenced by "p gboref^and is located in the node that 
has its own node_table referenced by "p dbo_tableref*I7 If the first 
E£?2 es 2«2 n J: h * $»»£•£** exclusive use ©f the database object, then 
SSiL-«S ES^^L&JP* 1 *** *««•*» ta bJta^BlO, otherwise all 
S^TO &?*- ZX&^MS 11 ** *«*••* an4 that are ;** front (in the 

«!if i 5?J h 5«2r 8 LS roe H a SSf^J^: ilw 4****«*« object •'/ 

/S 1 ^.£iS d T5 i r5 t -^ w,or ^' *j^/dbWa*-> l H?oeaf*» pjboref, eos); 
/• Check if the process wants exoluaive use oFthe database object •/ 
if extract (prbwef, "process. atoesa_typen » *exclusive^ 
then do; 

/•Unblock the process •/ 

cell find_ovner_( owner ref, "node->proc«as" prooref); 

98^4 ^*r%Jp?<xm, *nods/dboyS-^»oaa#»v "first", ownerref); 

i J? l ff ^.T*°5^*Wl^ w **3»1*-*l» resource •/ 
««11 ita*rt._Tp__db©ref, "prooess->dbe*, *«*»**, prooref): 
^!L G0 L* h * »«t« ^.the wpooefts. dbo and nodes involved •/ 
dbo_jns*e = extract (p_dboref, "dbo. name"): 
dbo_node_nsae * extract (p_d bo t abler* f, "node table. nam*"); 
process naae * extrsotJTprocreF, "process. name*); 



proo^node nsae « extreot_( ownerref, "node._table.name"); 

/■ Check If the process raining sooess to the database object 

the saae node as the dbo •/ 
if proc_node_name s dbo_node_name 
then do: 

call write_list_( "Process", process_name, "at node", 



is in 



call write_lis 



else do; 



return; 
end; 



proc node_name , "is given exclusive use of"); 
e_liat_(" ", dbo_name, "at node", 
abo_node_naae) ; 



Create a control message for a remote resourc 
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allocation and send it across nodes. */ 
call dcl_rem_res«rant(dbo_node_name f dbo_name, 

proc_node_.name, proeesa_name , eont_msg_numb) ; 
call write list_( "Control message number", eont_msg_numb, 
T sent from", dbo_node_name, "to", 
proc_node_name) ; 
call write list_(" granting", process_name, 

"exclusive use of", dbo_name); 
return; 
end; 
end; 
else do while ("eos); 

/• The first process on the queue requested shared access •/ 

/* Unblock the process •/ 

call find_owner_(ownerref , "node->process" , procref); 

call removed procref , "node/dbo/mg->process" ) ; 

call insert_(procref , "node/dbo/mg->process 1 ', "first", ownerref); 

/• Give the process shared access to the database object */ 

call dcl_dbo sh_asmt(sh_asmtref): 

call insert_Tsh_asmtref , "dbo->dbo sh_asmt", "first", p dboref); 

call insert_Jsh_asmtref, "process->dbo_sh_asmt", "first", procref); 

/* Get the names of the process, dbo and nodes involved */ 

dbojname = extract_(p_dboref , "dbo. name"): 

dbo_node_name = extract (p_dbo tableref, "node table. name"); 

process name = extract_Tproeref , "prooess.name"); 

proc_node name = extract_( ownerref , "node_table.name"); 

/* Check if the process gaining access to the database object is in 

the same node as the dbo */ 
if proc_node_jname = dbo_node_name 
then do; 

call write_list_( "Process", process_name , "at node", 

proc node_name, "is granted shared access to"); 
call write list_(" ", dbo_name, "at node", 

abo_node_name) ; 
end; 
else do; 

/* Create a control message for a remote resource 

allocation and send it across nodes. */ 
call dcl_rem_res «rant(dbo_jiode_ttame, dbo_name, 

proc node_name. process_name, cont_msg_numb) ; 
call write list_( "Control message number", cont_msg_numb, 
T sent from", dbo_node_name, "to", 
proc_node_name) ; 
call write list_(" granting", process_name, 

"shared access to w , dbo_name); 
end: 
/* Find what is now the first process queued for the database 

object •/ 
call rind_first_( procref , "node/dbo/mg->process", p_dboref, eos); 
/* If this process wants exclusive control of the database object it 
must remain blocked and we will not remove any more processes 
from the queue */ 
if extract_( procref . "process. aceess_type") = "exclusive" 

then eos = "1"b; 
end; 
return: 
end REL: 
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/• DDH_serv_rou tines. inol. pi 1 

The following declarations ere of the DDM servioe routines */ 

del oheok_for_d«adloolc entry (fixed bin(17), ohar(12), 

ohar(12), bit(1J); 
J . /• Looated within Procedure OBPL */ 

del dol_dbo entry(fixed bin(17), char(12)); 

_ , _._ /• Located within Procedure DDM •/ 
del dol_dbo_sh_afl»t entry (fixed B$»<17)); 

/^Located within Procedure DDM •/ 
del dol_oontPol_pessa«e entry (fixed binOj). char (20), 

„_ -fSxatf* bin) i 

/• Located within Procedure DDM •/ 
del dol fc jiode_tahle entry(fixed bin(17), char(12)); 

/♦Located within Procedure DDM^/ 
del del__obpl entry(fixod bin(17), ohar(12), 

©*BWtia>Vi*har(7)); 
/• Looated within Procedure DDM*/ 
dcl_.obpl_cont.jef entry (fixed bin(17), ohar(12), 

" irCT2?}! 

/• Looated within Proce5ure~DDM •/ 



del 



/• Located within Procedure DDMV 
»try entry (fixed t 

/• Looated within Procedure DDM •/ 
del dcl_process entry (fixed Mfl(tT), char (12)); 



/" Located within Procedure . 

del dcl_proo_entry entry (fixed bin(17), char (12), 

* t*)); 



del del_proc_term entry(char(12). char(»), char(12)); 

/• Located within Procedure ROLcA •/ 
del dcl_re*_jrea._jr»iit entry (charft?). char(»). char(12), 

chifiK*), fixed bin); 
/• Looated within Prooedure DDM •/ 
del find_entity_loc entry(flxed bin(17). ohar(20), 

fixed bin(17>, ehar(12). 
ehar(M)) returns (bit(1)); 
/» Located within Prooedure DDM*/ 
del exp_obpl entrytfixed bin(17), ehar(12)); 

/•Located within Prooedure OHPL 1 / 
del initlate.obpl entry(eharri2>, ohar<»), ehar(12), 

oharn2Tr«*haf(7>); 
/• Loeated within Prooedure DDM •/ 
del obpl_*dd_re»otiroe entryTfixed bin(17), fixed bin(17), 

- rn2),'bit?1)); 

del ree^roc_froa queue entryTfixed hin(17), fixed bin(17)); 

/•^Eoeatad within Prooedure REL •/ 



ohar_12), bit(1)); 
/• Looated within Prooedure OlPt •/ 

entryTfix 



del rldbo entryf ohar (*) , #har<*), char(»), 

ohar(*)J; 
/• Loeated within Prooedure REL */ 
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ADT_primitivea 



/•75-1 

These 

del 

del 

del 

del 
del 



del 
del 
del 
del 

del 

del 
del 
del 

del 

del 

del 

del 

del 
del 

del 



del 
del 
del 
del 

del 



del 



2-29 ADT_p 

are ADT primitives designed t 
add_ 

alter_ 

append_ 



definition 



break_ 

create attribute 



create_catalog_object_ 
create_entity_ 
create_group_ 
create_order_ 

create_relationship_ 

deleted_ 

delete_entity_ 

divide. 

empty_ 

empty_i ntersect ion_ 

entity_class_name_ 

entity_order_name_ 

exception, 
extract. 

find_associatively_ 



find_catalog_object_ 
find_direct_ 
find_each_ 
find_first_ 

find_first_intersection_ 



find_first_union_ 



rimi tives . incl . pi 1 
o assist the function 

entry (char (128), char (12 

returns (char ( 1 28) var 
entry(fixed bin(17), char(«l4) f 

char(»)): 
entry(fixed bin(17), char(20), 
char(6), fixed bin(17)); 
entry (fixed bin? 17)); 



writer ■/ 



del 


find_last_ 


del 


find_next_ 


del 


find_next_intersection. 


del 


find_next_union_ 


del 


find_owner_ 


del 


find_prior_ 


del 


insert_ 


del 


inserted_ 



ed binmi, 
(10), fixed 

fixed bin(17 
fixed bin(17 
fixed bin(17 
.fixed bin(17! 
char(20)); 
entry (fixed bin(17), 
ehar(9))j , %% 
entry (fixed bin(17)) 
entryefixed bin07), 
en try (char (128), chai 



entry (fixed 
char * 
;har 

entry 

entry 

entry 

entry 



char(IM), 
bin(17), 




entry 
entry 
entry 
entry 



Hi 



char(20), 

returas(bitO)); 
char(20)); 
. „'[128)) 

returns Tohari 128) varying); 
entry(fixed bin(17), char(20)) 

returns(bit(1)); 
entry(fixed bin(17), char(20), 

fixed bin(17), char (20)) 

returns(bit(1)); 
entry (fixed bin(17)) 

returns (char (20) ) ; 
entry(fixed bin(17), char(20)) 

returna(bit(1)); 
entry : 
entry(fixed bin(17). char(Mi»)) 

returns (char (128) varying); 
entry( fixed bin(17), ehar(20), 

fixed bin(17), char (128) varying, 
har(4M). bith)); , M 
fixed bin(17), char(» 
fixed bin(17), char(» 
fixed bin(17), bit(1),, 
fixed bin(17), char(20), 

fixed bin(17), bit(1)): 
entry (fixed bind 7), char (20), 

fixed bin(17), char(20), 

fixed bin(17), bit(1)): 
entry (fixed bin(17), char (20), 

fixed bin(lf), char(20), 

fixed bin(17), bit(1)): 
entry(fixed bin(17), ehar(20), 

fixed bin(17), bit(1)): 
entry( fixed bin(17), char(20), 

bit(D): 
entry(fixed bin(17), char(20), 

char (20), bit(1)); 
entry( fixed bin(17), char(20), 

fixed bin(17), char(20), 

fixed bin(17), 

entry (fixed bin(17) 

fixed bin(17)); 
entry(fixed bin(17), char(20), 

bit(1)); 
entry(fixed bin(17), char(20), 

char(6), fixed bin(17))j 
entry(fixed bin(17), char(20)) 

returns(bitd)); 



bit(1))i 
, ehar(20 



), 
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del last_of_set_ 

del member_ 

del member_eount_ 

del name_catalog_object_ 

del multiply. 

del owner_ 

del remove_ 

del sort_relationship_ 

del subtract_ 

/• The following are global reference 

del changemode 

del SF_REF 

del CN REF 

del PR?JC_REF 

del PSPH_REF 

del PSSG_REF 

del returncode 

del SYS_REF 

del tracemode 



entry (fixed bin(17 
returns (bit(1 

entry(fixed bin(17 
returns (bit(1 

entry( fixed bin(17 



char(20)) 
char(20)) 
ehar(20)) 



returns(fixed bin(17)); 
entry (fixed bin(17)) 

returns(char(44) varying); 
entry(char(128), char(128)) 

returns (char (128) varying); 
entry(fixed bin(17J, char(20)7 

returns (bit(1, 
entry (fixed bin(17 
entry (fixed bin(17 



'J; 



char(20)): 

:i?8), 



char(20)); 
char(20), 



entry (char (128), char(128)) 

returns (char (128) varying); 
variables used by modellers */ 
external static; 
external static init 
external static init 
external static init 
external static init 
external static init 
fixed binary external static init(0 
fixed bin(17) external static init( 
bit(1) external static init("0"b); 



fixed bin 
fixed bin 
fixed bin 
fixed bin 
fixed bin 



17 
17 
17 
17 
17 



fixed bin(17' 



0) 
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Appendix III 

This appendix contains examples of several deadlock and "near deadlock" 
situations, thus demonstrating various features of the deadlock detection al- 
gorithm presented in Chapter VI. In the case where a deadlock is detected, a 
final state diagram is given, whereas in the examples where no deadlock is 
detected, an important intermediate state is also shown. A key to the 
diagrams appears on the next page. Diagrams appear on a page with a header 
containing the name(s) of the associated scenario(s). Each diagram immedi- 
ately follows the first scenario with which it is associated. 

It should be noted that before the commands specific to each example were 
executed, after the system state was reinitialized, the commands in file 
"deraoO" were executed. 
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Key for State Diagrams of Demonstration Scenarios 



y^gX 



©- 



- VagK 



@-« <fcon\<- - - -@ 



(opfl 




con J 



access_type 



-Idbok 



©" 



access_type 



Hdbok 




city 



Represents process "pi" as the initiator of message 
group "mgj". (g) and /mgj\ are always in the same 
node for this representation. 

Represents process "pi" as the acceptor of message 
group "mgj" and "pi" is currently waiting for a mes- 
sage in "mgj". @ and ymgj\ need not be in the 
same node for this representation. 

Represents process "pk" waiting for a message from 
operator "opi" over operator connection "eonj". 

Represents operator "opi" waiting for a message from 
process "pk" over operator connection "conj". 

Represents process "pi" as having access to database 
object "dbok". The type of access is specified by 
"aceess_type" . @) and |dbok| need not be in the 
same node. 

Represents process "pi" as waiting for access to 
database object "dbok". The type of access desired 
is specified by "access_type". (g) and |dbok| need 
not be in the same node. 

Represents a node with the node name specified by 
"city". (g) and [dbok] drawn "within" this node 
represent processes and database objects located 
within the node specified by "city". /mgj\ drawn 
"within" the node represents a message group that was 
initiated by a process located in the node specified 
by "city". 
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scenario demoO 
sysgen 

System created 
cnode Boston 

Node created: 
cnode Phoenix 

Node created: 
cproc Boston p1 

Process 



Boston 
Phoenix 



cproc Boston p2 

Process p2 
cproc Boston p3 

Process j>3 
cdbo Boston dbol 

Database object 
cdbo Boston dbo2 

Database object 
cproc Phoenix p1 

Process pi 



p1 created in node Boston 



created in node Boston 
created in node Boston 



dbol 
dbo2 



created in node 
created in node 



Phoenix 



Boston 
Boston 



created in node Phoenix 
created in node Phoenix 



dbol 
dbo2 



created in node 
created in node 



created in node 
cproc Phoenix p2 

Process pi 
cproc Phoenix p3 

Process p; 
cdbo Phoenix dbol 

Database object 
cdbo Phoenix dbo2 

Database object 
cnode Cambridge 

Node created: 
cproc Cambridge p1 

Process p1 created in node 
cproc Cambridge p2 

Process p2 created in node 
cproc Cambridge p3 

Process p3 created in node 
cdbo Cambridge dbol 

Database object dbol created in node 
cdbo Cambridge dbo2 

Database object dbo2 created in node 



Phoenix 
Phoenix 



Cambridge 



Cambridge 
Cambridge 
Cambridge 



Cambridge 
Cambridge 
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scenario demo_bug 

note This is an example of a ease where a deadlock involving two 
note processes and two resources located in two nodes is detected, 
note when in fact no deadlock exists. The reason a deadlock is 
note detected is that an OBPL sent from Boston to Phoenix had its 
note arrival delayed long enough so that p1 in Phoenix could release 
note dbol in Boston, request access to it again, gain use of the 
note database object and then request access to and get queued for 
note dbol in Phoenix before Phoenix examined the OBPL. The first 
note seven commands set up the state where p1 in Phoenix has exclusive 
note use of dbol in Boston, p1 in Boston has shared use of dbol in 
note Phoenix, p1 in Boston is blocked waiting for shared use of dbol 
note in Boston, and an OBPL has been sent to Phoenix by Boston, 
rqdbo shared Boston p1 Phoenix dbol 

Process p1 at node Boston is blocked while a request is sent to 

the node containing the desired resource 
Control message number 1 sent from Boston to Phoenix 
representing a remote resource request 
rcvcm 1 

Control message number 1 representing a remote resource request 

has been received 
p1 at node Boston is granted shared access to 

dbol at node Phoenix 
Control message number 2 sent from Phoenix to Boston 
representing this allocation 
rcvcm 2 

Control message number 2 representing a remote resource allocation 

has been received 
p1 at node Boston has been granted shared access to 

dbol at node Phoenix 
rqdbo exclusive Phoenix p1 Boston dbol 

Process pi at node Phoenix is blocked while a request is sent to 

the node containing the desired resource 
Control message number 3 sent from Phoenix to 
representing a remote resource request 
rcvcm 3 

Control message number 3 representing a remote 

has been received 
p1 at node Phoenix is granted exclusive use of 

dbol at node Boston 
Control message number 4 sent from Boston to Phoenix 
representing this allocation 
rcvcm 4 

Control message number 4 representing a remote resource allocation 

has been received 
p1 at node Phoenix has been granted exclusive use of 

dbol at node Boston 
rqdbo shared Boston p1 Boston dbol 

Resource not available, process blocked. 

Control message number 5 sent from Boston to Phoenix 
representing an OBPL 
note Do not let the OBPL be received at this time. Let pi in Phoenix 
note release dbol in Boston, so that p1 in Boston will be awakened and 
note granted shared use of dbol in Boston, 
rldbo Phoenix p1 Boston dbol 

Control message number 6 sent from Phoenix to 
representing a remote resource release 
rcvcm 6 

Control message number 6 representing a remote 

has been received 
dbol at node Boston has been released by 

p1 at node Phoenix 

Process p1 at node Boston is granted shared access to 

dbol at node Boston 
note Let p1 in Phoenix request access to dbol in Boston for the 
note second time, and let it be granted shared use of the database 
note object. 



Boston 



resource request 



Boston 



resource release 
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resource request 



to Phoenix 



resource allocation 



rqdbo shared Phoenix p1 Boston dbol 

Prooess p1 at node Phoenix is blocked while a request is sent to 

the node containing the desired resource 
Control message number 7 sent from Phoenix to Boston 
representing a remote resource request 
rcvcm 7 

Control message number 7 representing a remote 

p1 at node Phoenix is granted shared access to 

dbol at node Boston 
Control message number 8 sent from Boston 
representing this allocation 
rcvcm 8 

Control message number 8 representing a remote 

has been received 

pi at node Phoenix has been granted shared access to 

dbol at node Boston 
note Let pi in Phoenix request exclusive use of dbol in Phoenix, 
note The process will be blocked and an OBPL will be sent to Boston 
note where it will be discarded because p1 in Boston is active, 
rqdbo exclusive Phoenix p1 Phoenix dbol 

Resource is not currently available for exclusive use, process p1 

at node Phoenix is blocked. 
Control message number 9 sent from Phoenix to Boston 
representing an OBPL 
rcvcm 9 

Control message number 9 representing an OBPL has been received, 
note Now let Phoenix receive the OBPL that was previously sent by 
note Boston. A "false" deadlock will be detected because pi in Phoenix 
note is blocked and has access to dbol in Boston, even though this is 
note not the same assignment of the resource that was used when the 
note OBPL was created, 
rcvcm 5 

Control message number 5 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

p1 at node Boston 

pi at node Phoenix 

End of deadlock list 
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exclusive 



shared 



Boston 




Phoenix 



State where control message 5 representing an OBPL has Just been sent 
from Boston to Phoenix. Receipt of the OBPL is delayed until after the state 
drawn below has drawn been reached. 




shared 



shared 




Phoenix 



Final State Diagram 
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scenario demol 

note This is an example of a two process two resource deadlock in a 

note single node. No control messages and no operators are involved 

note in the detection of this deadlock. 

initmg mg1 Boston p2 Boston 

Message group mg1 has been initiated 
accepting mg1 Boston pi 

mgl has been accepted by p1 at node Boston 
rqdoo shared Boston pi Boston dbol 

p1 at node Boston granted shared access to dbol at node Boston 
rqdbo exclusive Boston p2 Boston dbol 

Resource is not currently available for exclusive use, process p2 
at node Boston is blocked, 
rcvmsg mg1 

Process p1 at node Boston is blocked waiting for a 

message in message group mg1 
A deadlock has been detected. The following processes are involved: 

p1 at node Boston 

p2 at node Boston 

End of deadlock list 




Boston 
Final State Diagram 
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scenario demo2 

note This is an example of a two process two resource deadlock 

note involving two nodes. The first three commands create the state 

note where both processes are active and both involved resources have 

note been allocated to the proper processes. 

rqdbo exclusive Phoenix p1 Phoenix dbol 

p1 at node Phoenix Is granted exclusive use of dbol at node Phoenix 
initmg mg2 Cambridge p1 Phoenix 

Message group mg2 has been initiated 
accepting mg2 Phoenix p1 

mgz has been accepted by p1 at node Phoenix 
rqdbo shared Cambridge p1 Phoenix dbol 

Process p1 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 1 sent from Cambridge to Phoenix 
representing a remote resource request 
note We will delay the receipt by Phoenix of this resource request, 
rcvmsg mg2 

Process p1 at node Phoenix is blocked waiting for a 

message in message group mg2 
Control message number 2 sent from Phoenix to Cambridge 
representing an OBPL 
rcvcm 2 

Control message number 2 representing an OBPL has been received. 
Control message number 3 sent from Cambridge to Phoenix 
representing an OBPL 
note This OBPL contains entries for p1 in Phoenix and p1 in Cambridge, 
note It will be discarded by Phoenix because Phoenix has no record that 
note pi in Cambridge is waiting for dbol in Phoenix since control 
note message 1 still has not been reoeived. 
rcvcm 3 

Control message number 3 representing an OBPL has been received, 
rcvcm 1 

Control message number 1 representing a remote resource request 

has been received 
Resource not available, prooess remains blocked. 
Control message number M sent from Phoenix to Cambridge 
representing an OBPL 
note This OBPL contains entries for p1 in Cambridge and p1 in Phoenix, 
note It states that pi in Phoenix is waiting for a message in message 
note group mg2. Cambridge will verify that the desired message has 
note not been sent, and a deadlock will be detected, 
rcvcm H 

Control message number 4 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

p1 at node Cambridge 

p1 at node Phoenix 

End of deadlock list 
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scenarios demo2 demo3 demo** 




Phoenix 



Cambridge 



Final State Diagram 
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scenario demo 3 

note This is an example of a two process two resource deadlock 

note involving two nodes. The first three commands create the state 

note where both processes are active and both involved resources have 

note been allocated to the proper processes. 

rqdbo exclusive Phoenix p1 Phoenix dbol 

p1 at node Phoenix is granted exclusive use of 
initmg mg2 Cambridge p1 Phoenix 

Message group mg2 has been initiated 
^hc 



dbol at node Phoenix 



accepting mg2 Phoenix p1 

mgz has been accepted b 
rqdbo shared Cambridge p1 P 



noenix 



at node 
dbol 



Phoenix 



"Process p1 ?* J ?°??_1 Cambridge is blocked while a request is sent to 



he node containing the desired resource 
Control message number 1 sent from Cambridge to Phoenix 
representing a remote resource request 
We will delay receipt by Phoenix of this resource request just 
long enough to block p1 in Phoenix (which controls dbol in Phoenix) 
and send an OBPL to Cambridge. In this way, after receipt of the 
resource request, we will have two OBPL's outstanding, and the same 
deadlock will be detected twioe. 



note 
note 
note 
note 
note 

rcvmsg mg2 
Process 



pi at node Phoenix 

message in message group mg2 
Control message number 2 sent from Phoenix 
representing an OBPL 
rcvcm 1 

Control message number 1 representing a remote 

has been received 
Resource not available, process remains blocked. 
Control message number 3 sent from Phoenix 
representing an OBPL 
rcvcm 2 

Control message number 2 representing an OBPL 
Control message number 4 sent from Cambridge 
representing an OBPL 
rcvcm 3 

Control message number 3 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

p1 at node Cambridge 

pi at node Phoenix 

End of deadlock list 
rcvcm 1} 

Control message number 4 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

p1 at node Phoenix 

p1 at node Cambridge 

End of deadlock list 



is blocked waiting for a 
to Cambridge 



resource request 



to Cambridge 



has been received, 
to Phoenix 
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scenario demoM 



scenario demo4 



dbol at node Phoenix 



This is an example of a two process two resource deadlock 

note involving two nodes. The first three commands create the state 
note where both processes are active and both involved resources have 
note been allocated to the proper processes, 
rqdbo exclusive Phoenix p1 Phoenix dbol 

p1 at node Phoenix is granted exclusive use of 
initmg mg2 Cambridge p1 Phoenix 

Message group mg2 has been initiated 
accepting mg2 Pnoenix p1 

■g2 has been accepted by p1 at node Phoenix 
rqdbo shared Cambridge p1 Pnoenix dbol 

Process p1 at node Cambridge is blocked while a request is sent to 
th< 



Phoenix 



the node containing the desired resource 
Control message number 1 sent from Cambridge to 
representing a remote resource request 
note We will allow this resource request to be immediately received 
note by Phoenix. No OBPL will be generated because pi in Phoenix is 
note active, and it controls dbol in Phoenix. By default, control 
note messages generated in the future will be received immediately 
note after they are sent, and the deadlock will be detected once, 
rcvcm 1 

Control message number 1 representing a remote 

has been received 
Resource not available, process remains blocked, 
rcvmsg mg2 

Process p1 at node Phoenix is blocked waiting for a 

message in message group mg2 
Control message number 2 sent from Phoenix 
representing an OBPL 
rcvcm 2 

Control message number 2 representing an OBPL 
Control message number 3 sent from Cambridge 
representing an OBPL 



resource request 



to Cambridge 



has been received. 
to Phoenix 



rcvcm 3 



Control message number 3 representing an OBPL 
A deadlock has been detected. The following pr 

p1 at node 

p1 at node 

End of deadlock list 



has been received, 
processes are involved: 
Phoenix 
Cambridge 
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proper processes . 



mgl has been aocepted by p1 
rqdbo shared Cambridge p! Cambridgi 
p1 at node Cambridge granted a 



dbol at node Cambridge 



scenario demo5 

note This is an example of a state where two deadlocks exist 
note involving four processes and four resources located in three 
note nodes. Two deadlocks are involved because dbol in Cambridge 
note has two shared^ users, the first :ffc ;ejommihas create the state 
note where all the involved, processes are active and all the involved 
note resources have been allocated to the 
initmg mg1 Boston pi Cambridge 

Message group mgl has been initiated 
accepting mgl Cambridge pi 

at node Cambridge 
je dbol 

^. ~ _- shared access to 

rqdbo shsred Boston p1 Cambridge dbol 
Process pi at node Boston la blocked while a request is sent to 

the nokle «eitiiB sired resource 
Control message number 1 ; stot froa Boston to Cambridge 
representing a remote resource request 
rcvcm 1 

Control message number f representing a remote resource request 

has been received 
p1 at node Boston Is granted shared access to 

dbol -'■■ at node Cambridge . .:.. 
Control message number 2 ;a«rt from Cambridge to Boston 
representing this allocation 
rcvcm 2 

Control message number 2 representing a remote resource allocation 

has been received 
p1 at node Boston has been granted shared access to 

dbol at node Cambridge 
rqdbo exclusive Cambridge p2 Phoenix dbol 



Process 



g. &?&*M% jj^iffi. 



e a request is sent to 



Control message number 3 senf from Cambridge to Phoenix 

representing a remote resource request 
rcvcm 3 

Control message number 3 representing a remote resource request 

has been received 
p2 at node Cambridge is granted exclusive use of 

dbol at node Phoenix 
Control message number k sent from Phoenix to Cambridge 

representing '-'this- allocation 



rcvcm 4 
Control 



P2 



message number 4 representing a remote resource allocation 
has been reoelved 

at node Cambridge has been granted exclusive use of 
dbol ajt node Phoenix 
rqdbo shared Phoenix p1 Phoenix d$o2 

pi at node Phoenix granted" shared aeoeas to dbo2 at node Phoenix 
rqdbo exclusive Boston pT >of 
Process pi at node Boston is blocked while a request is sent to 

the node containing the desired resource 
Control message number 5 sent from Boston to Phoenix 
representing a remote resource request 
note No OBPL will be sent to another node, and no deadlock will 
note be detected beoauae p1 at node Phoenix is active and is the only 
note process that has access to dbo2 in Phoenix, 
rcvcm 5 

Control message number 5 representing a remote resource request 

has been received 
Resource is not currently available for exoluaive use, process p1 
at node Boa ton remains blooked 
rqdbo shared Phoenix p1 Phoenix dbol 
Resource not available, prooeaa blooked. 

Control message number 6 sent from Phoenix to Cambridge 
representing an OBPL 



157 



Appendix III 



scenario demo5 



note No deadlock will be detected because p2 in Cambridge is active, 
rcvcm 6 

Control message number 6 representing an OBPL has been received. 
note This next request will create a three process three resource 
note deadlock. An OBPL will be created, ana we will immediately pass 
note it from node to node in order to detect the deadlock, 
rqdbo exclusive Cambridge p2 Cambridge dbol 

Resource is not currently available for exclusive use, process p2 

at node Cambridge is blocked. 
Control message number 7 sent from Cambridge 
representing an OBPL 
rcvcm 7 

Control message number 7 representing an OBPL 
Control message number 8 sent from Boston 
representing an OBPL 
rcvcm 8 

Control message number 8 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

p2 at node Cambridge 

p1 at node Boston 

p1 at node Phoenix 

End of deadlock list 
note The next command will create a four process four resource deadlock, 
note Due to the fact that two processes have shared access to dbol in 
note Cambridge, both this newly created deadlock, and the previously 
note detected deadlock will be detected when the OBPL is created and 
note passed among the nodes. 



to Boston 



has been received, 
to Phoenix 



rcvmsg mg1 
Process 



p1 at node Cambridge 

message in message group mg1 
Control message number 9 sent from Cambridge 
representing an OBPL 
rcvcm 9 

Control message number 9 representing an OBPL 
Control message number 10 sent from Boston 
representing an OBPL 
rcvcm 10 

Control message number 10 representing an OBPL 
Control message number 11 sent from Phoenix 
representing an OBPL 
rcvcm 1 1 

Control message number 



is blocked waiting for a 



to Boston 



has been received, 
to Phoenix 



has been received, 
to Cambridge 



A deadlock has been detected 

p ! 

P J 

p l 
p2 

End of deadlock list 

A deadlock has been detected. 

p l 

p l 
P2 

End of deadlock list 



1 1 representing an OBPL has been received. 



The following processes are involved: 



at node 
at node 
at node 
at node 



Cambridge 
Boston 
Phoenix 
Cambridge 



The following processes are involved: 
at node Boston 
at node Phoenix 
at node Cambridge 
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Cambridge 



Final State Diagram 
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scenario demo6 

note This is an example of a state where two deadlocks exist 
note involving four processes and four resources located in three 
note nodes, two deadlocks are involved because dbol in Cambridge 
note has two shared users. The first 10 commands create the state 
note where all the involved processes are active and all the involved 
note resources have been allocated to the proper processes. 
initmg mg1 Boston p1 Cambridge 

Message group mgl has been initiated 
acceptmg mg1 Cambridge p1 

mg1 has been accepted by p1 at node Cambridge 
rqdbo shared Cambridge p1 Cambridge dbol 

p1 at node Cambridge granted shared access to dbol at node Cambridge 
rqdbo shared Boston p1 Cambridge dbol 

Process p1 at node Boston is blocked while a request is sent to 

the node containing the desired resource 
Control message number 1 sent from Boston to Cambridge 
representing a remote resource request 
rcvcm 1 

Control message number 1 representing a remote resource request 

has been received 
pi at node Boston is granted shared access to 

dbol at node Cambridge 
Control message number 2 sent from Cambridge to Boston 
representing this allocation 
rcvcm 2 

Control message number 2 representing a remote resource allocation 

has been received 
p1 at node Boston has been granted shared access to 

dbol at node Cambridge 
rqdbo exclusive Cambridge p2 Phoenix dbol 

Process p2 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 3 sent from Cambridge to Phoenix 
representing a remote resource request 
rcvcm 3 

Control message number 3 representing a remote resource request 

has been received 
p2 at node Cambridge is granted exclusive use of 

dbol at node Phoenix 
Control message number 4 sent from Phoenix to Cambridge 
representing this allocation 
rcvcm 4 

Control message number 4 representing a remote resource allocation 

has been received 
p2 at node Cambridge has been granted exclusive use of 

dbol at node Phoenix 
rqdbo shared Phoenix pi Phoenix dbo2 

pi at node Phoenix granted shared access to dbo2 at node Phoenix 
rqdbo exclusive Boston pi Phoenix dbo2 

Process p1 at node Boston is blocked while a request is sent to 

the node containing the desired resource 
Control message number 5 sent from Boston to Phoenix 
representing a remote resource request 
note p1 in Phoenix is active, so there will be no deadlock when the 
note remote resource request is received from Boston. 
rcvcm 5 

Control message number 5 representing a remote resource request 

has been received 
Resource is not currently available for exclusive use, process p1 
at node Boston remains blocked 
rqdbo shared Phoenix p1 Phoenix dbol 

Resource not available, process blocked. 

Control message number 6 sent from Phoenix to Cambridge 



representing an OBPL 
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has been received, 
to Phoenix 



has been received, 
to Cambridge 



note p2 in Cambridge is active, so the OBPL will be discarded after 
note it is received by Cambridge, 
revcm 6 

Control message number 6 representing an OBPL has been received, 
rcvmsg mg1 

Process p1 at node Cambridge is blocked waiting for a 

message in message group mg1 
Control message number 7 sent from Cambridge to Boston 
representing an OBPL 
note p2 in Cambridge is active, so the OBPL will be discarded when 
note it reaches Cambridge, 
rcvcm 7 

Control message number 7 representing an OBPL 
Control message number 8 sent from Boston 
representing an OBPL 
rcvcm 8 

Control message number 8 representing an OBPL 
Control message number 9 sent from Phoenix 
representing an OBPL 
rcvcm 9 

Control message number 9 representing an OBPL has been received. 

This next request will create two deadlocks, due to the fact that 
dbol in Cambridge has two readers. Two OBPL's will be generated, 
and both deadlocks will be detected when their respective OBPL's 
arrive in Phoenix. The OBPL's need not return to Cambridge 
because p2 in Cambridge was the first process to be placed in the 
OBPL's, and Phoenix knows that p2 in Cambridge oontrols dbol 
in Phoenix, 
rqdbo exclusive Cambridge p2 Cambridge dbol 

Resource is not currently available for exclusive use, process p2 

at node Cambridge is blocked. 
Control message number 10 sent from Cambridge 

representing an OBPL 
Control message number 11 sent from Cambridge 
representing an OBPL 
revcm 10 

Control message number 10 representing an OBPL 
Control message number 12 sent from Boston 
representing an OBPL 
rcvcm 12 

Control message number 



note 
note 
note 
note 
note 
note 
note 



to Boston 
to Boston 



has been received. 
to Phoenix 



12 representing an OBPL has been received. 
The following processes are involved: 



Cambridge 
Cambridge 
Boston 
Phoenix 



deadlock has been detected. 

p2 at node 

p1 at node 

p1 at node 

p1 at node 

End of deadlock list 
rcvcm 1 1 

Control message number 11 representing an OBPL 
Control message number 13 sent from Boston 
representing an OBPL 
rcvcm 13 

Control message number 



has been received. 
to Phoenix 



A deadlock has been detected. 

P1 
P1 
End of deadlock list 



13 representing an OBPL has been received. 



The following processes are involved: 
at node Cambridge 
at node Boston 
at node Phoenix 
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Boston 



resource request 



scenario demo7 

note This is an example of a state where three deadlocks exist 
note involving six processes and five resources located in three 
note nodes. Three deadlocks are involved because dbo2 in Boston 
note has three shared users. Five, rather than six, resources are 
note involved because two processes are waiting for the same database 
note object. The first 18 commands create the state where all the 
note involved processes are active and all the Involved resources 
note have been allocated to the proper processes, 
rqdbo shared Boston p1 Boston dbo2 

?1 at node Boston granted shared access to dbo2 at node Boston 
tmg mgl Phoenix p1 Boston 
Message group mg1 has been initiated 
accepting mg1 Boston pi 

mgl has been accepted by p1 at node Boston 
rqdbo exclusive Phoenix p2 Boston dbol 

Process p2 at node Phoenix is blocked while a request is sent to 

the node containing the desired resource 
Control message number 1 sent from Phoenix to 
representing a remote resource request 
rcvcm 1 

Control message number 1 representing a remote 

has been received 
p2 at node Phoenix is granted exclusive use of 

dbol at node Boston 
Control message number 2 sent from Boston to Phoenix 
representing this allocation 
rcvcm 2 

Control message number 2 representing a remote resource allocation 

h&S D66H PGGftiVGd 

p2 at node Phoenix has been granted exclusive use of 

dbol at node Boston 
rqdbo shared Cambridge p1 Boston dbo2 

Process p1 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 3 sent from Cambridge to Boston 

representing a remote resource request 
rcvcm 3 

Control message number 3 representing a remote resource request 

has been received 
pi at node Cambridge is granted shared access to 

dbo2 at node Boston 
Control message number 4 sent from Boston to Cambridge 

representing this allocation 
rcvcm t 

Control message number 4 representing a remote resource allocation 

has been received 
pi at node Cambridge has been granted shared access to 

dbo2 at node Boston 
rqdbo shared Cambridge p2 Boston dbo2 

Process p2 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 5 sent from Cambridge to Boston 

representing a remote resource request 
rqdbo shared Phoenix pi Cambridge dbol 

Process p1 at node Phoenix is blocked while a request is sent to 

the node containing the desired resource 
Control message number 6 sent from Phoenix to Cambridge 

representing a remote resource request 
rcvcm 5 

Control message number 5 

has been received 
p2 at node Cambridge is granted shared access to 

dbo2 at node Boston 
Control message number 7 sent from Boston to Cambridge 

representing this allocation 



representing a remote resource request 
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resource request 



rcvcm 6 

Control message number 6 representing a remote 

has been received 
P 1 JW „ at node Phoenix is granted shared access to 

dbol at node Cambridge 
Control message number 8 sent from Cambridge to Phoenix 
representing this allocation 
rcvcm 7 

Control message number 7 representing a remote resource allocation 

has been received 
P 2 JW „ at node Cambridge has been granted shared access to 
dbo2 at node Boston 
rcvcm 8 

Control message number 8 representing a remote resource allocation 

has been received 
P 1 Jw . at node Phoenix has been granted shared access to 

dbol at node Cambridge 
rqdbo exclusive Cambridge p3 Phoenix dbol 

Process p3 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 



to Phoenix 



resource request 



Control message number 9 sent from Cambridge 

representing a remote resource request 
rcvcm 9 

Control message number 9 representing a remote 

has been received 
P3 at node Cambridge is granted exclusive use of 

dbol at node Phoenix 
Control message number 10 sent from Phoenix to Cambridge 

representing this allocation 
rcvcm 10 

Control message number 10 representing a remote resource allocation 

has been received 
P3 at node Cambridge has been granted exclusive use of 

dbol at node Phoenix 



rcvmsg mg1 
Process 



is blocked waiting for a 
to Phoenix 
'be discarded by Phoenix because p1 is active. 

has been received. 



p1 at node Boston 

message in message group mg1 
Control message number 11 sent from Boston 
representing an OBPL 
note The OBPL will t 
rcvcm 11 

Control message number 11 representing an OBPL 
rqdbo shared Cambridge p1 Boston dbol 

Process p1 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 12 sent from Cambridge to Boston 
representing a remote resource request 
note The process that controls dbol in Boston is located in Phoenix, 
note and is active. Therefore, when Boston receives the resource 
note request, it will create an OBPL and send it to Phoenix, which 
note will then discard it. 
rcvcm 12 

Control message number 12 representing a remote 

has been received 
Resource not available, process remains blocked. 
Control message number 13 sent from Boston 
representing an OBPL 
rcvcm 13 

Control message number 13 representing an OBPL has been received, 
rqdbo exclusive Phoenix p2 Phoenix dbol 
Resource not available, prooess blooked. 

Control message number 14 sent from Phoenix to Cambridge 
representing an OBPL 
note The OBPL will be disearded by Cambridge beoause p3, which controls 
note dbol in Phoenix, is active, 
rovcm 14 

Control message number 14 representing an OBPL has been received. 
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P3 



to Phoenix 



representing a remote resource request 



to Cambridge 



has been received, 
to Phoenix 



has been received. 
When Boston receives 



rqdbo exclusive Cambridge p3 Cambridge dbol 

Resource is not currently available for exolusive use, process 

at node Cambridge is blocked. 
Control message number 15 sent from Cambridge to Phoenix 
representing an OBPL 
note The OBPL will be discarded by Phoenix beoause p1, which controls 
note dbol in Cambridge, is active, 
rcvcm 15 

Control message number 15 representing an OBPL has been received, 
rqdbo shared Cambridge p2 Phoenix dbol 

Process p2 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 16 sent from Cambridge 
representing a remote resource request 
rcvcm 16 

Control message number 16 
has Been received 
Resource not available, process remains blocked. 
Control message number 17 sent from Phoenix 
representing an OBPL 
note An OBPL is sent to Cambridge because p3 in Cambridge controls 
note dbol in Phoenix. p3 will be added to the OBPL which will then 
note be passed to Phoenix because p1 in Phoenix controls dbol in 
note Cambridge. The OBPL will then be discarded beoause pi is active, 
rcvcm 17 

Control message number 17 representing an OBPL 
Control message number 18 sent from Cambridge 
representing an OBPL 
rcvcm 18 

Control message number 18 representing an OBPL 
note The next request creates three deadlocks. 

note the remote resource request for dbo2, it creates three OBPL's 
note because there are three readers of the database object. We will 
note then allow the three OBPL's to be passed among nodes until all 
note three deadlocks have been detected, at which time there will be 
note no outstanding OBPL's or control messages, 
rqdbo exclusive Phoenix pi Boston dbo2 

Process p1 at node Phoenix is blocked while a request is sent to 

the node containing the desired resource 
Control message number 19 sent from Phoenix to Boston 
representing a remote resource request 
re vera 19 

Control message number 19 
has been received 
Resource is not currently available for exclusive use, process p1 

at node Phoenix remains blooked 
Control message number 20 sent from Boston 

representing an OBPL 
Control message number 21 sent from Boston 

representing an OBPL 
Control message number 22 sent from Boston 
representing an OBPL 
rcvcm 21 

Control message number 21 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

p1 at node Phoenix 

p1 at node Boston 

End of deadlock list 
rcvcm 20 

Control message number 20 representing an OBPL 
Control message number 23 sent from Cambridge 
representing an OBPL 
rcvcm 22 

Control message number 22 representing an OBPL 
Control message number 24 sent from Cambridge 
representing an OBPL 



representing a remote resource request 



to Cambridge 
to Phoenix 
to Cambridge 



has been received, 
to Boston 



has been received, 
to Phoenix 
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has been received, 
to Phoenix 



has been received, 
to Cambridge 



has been received. 



The following processes are involved: 
at node Phoenix 



rcvcm 23 

Control message number 23 representing an OBPL 

Control message number 25 sent from Boston 
representing an OBPL 
rcvcm 25 

Control message number 25 representing an OBPL 

Control message number 2o sent from Phoenix 
representing an OBPL 
rcvcm 26 

Control message number 26 representing an OBPL 

A deadlock has been detected. 

p! 

End of deadlock list 
rcvcm 2M 

Control message number 24 representing an OBPL 
Control message number 27 sent from Phoenix 
representing an OBPL 
rcvcm 27 

Control message number 27 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

pi at node Phoenix 

p2 at node Cambridge 

p3 at node Cambridge 

End of deadlock list 



at node 
at node 
at node 



Cambridge 

Phoenix 

Cambridge 



has been received, 
to Cambridge 
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shared 




shared 



Cambridge 



Final State Diagram 
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dbo2 at node Boston 



scenario demo8 

note This is an example of a state where three deadlocks exist 
note involving six processes and five resources located in three 
note nodes. Three deadlocks are involved because dbo2 in Boston 
note has three shared users. Five, rather than six, resources are 
note involved because two processes are waiting for the same database 
note object. The first 18 commands create the state where all the 
note involved processes are active and all the involved resources 
note have been allooated to the proper processes, 
rqdbo shared Boston p1 Boston dbo2 

p1 at node Boston granted shared access to 
initmg ragl Phoenix p1 Boston 

Message group mg1 has been initiated 
accepting mg1 Boston p1 

mgl has been accepted by p1 at node Boston 
rqdbo exclusive Phoenix p2 Boston dbol 

Process p2 at node Phoenix is blocked while a request is sent to 

the node containing the desired resource 
Control message number 1 sent from Phoenix to Boston 
representing a remote resource request 
rcvcm 1 

Control message number 1 representing a remote resource request 

has been received 
p2 at node Phoenix is granted exclusive use of 

dbol at node Boston 
Control message number 2 sent from Boston to Phoenix 
representing this allocation 
rcvcm 2 

Control message number 2 representing a remote resource allocation 

has been received 
p2 at node Phoenix has been granted exclusive use of 

dbol at node Boston 
rqdbo shared Cambridge p1 Boston dbo2 

Process p1 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 3 sent from Cambridge to Boston 
representing a remote resource request 
rcvcm 3 

Control message number 3 representing a remote resource request 

has been received 
p1 at node Cambridge is granted shared access to 

dbo2 at node Boston 
Control message number 4 sent from Boston to Cambridge 
representing this allocation 
rcvcm 4 

Control message number 4 representing a remote resource allocation 

has been received 
p1 at node Cambridge has been granted shared access to 

dbo2 at node Boston 
rqdbo shared Cambridge p2 Boston dbo2 

Process p2 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 5 sent from Cambridge to Boston 
representing a remote resource request 
rqdbo shared Phoenix pi Cambridge dbol 

Process pi at node Phoenix is blocked while a request is sent to 

the node containing the desired resource 
Control message number 6 sent from Phoenix to Cambridge 
representing a remote resource request 
rcvcm 5 

Control message number 5 representing a remote resource request 

has been received 
p2 at node Cambridge is granted shared access to 

dbo2 at node Boston 
Control message number 7 sent from Boston to Cambridge 
representing this allocation 
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resource request 



resource allocation 



resource allocation 



rcvcm 6 

Control message number 6 representing a remote 

has been received 
p1 at node Phoenix is granted shared access to 

dbol at node Cambridge 
Control message number 8 sent from Cambridge to Phoenix 
representing this allocation 
rcvcm 7 

Control message number 7 representing a remote 

has been received 

p2 at node Cambridge has been granted shared access to 

dbo2 at node Boston 
rcvcm 8 

Control message number 8 representing a remote 

has been received 
p1 at node Phoenix has been granted shared access to 

dbol at node Cambridge 
rqdbo exclusive Cambridge p3 Phoenix dbol 

Process p3 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 9 sent from Cambridge to Phoenix 
representing a remote resource request 
rcvcm 9 

Control message number 9 representing a remote 

has been received 
p3 at node Cambridge is granted exclusive use of 

dbol at node Phoenix 
Control message number 10 sent from Phoenix to Cambridge 
representing this allocation 
rcvcm 10 

Control message number 10 
has been received 

p3 at node Cambridge has been granted exclusive use of 

dbol at node Phoenix 
rqdbo exclusive Phoenix pi Boston dbo2 

Process p1 at node Phoenix is blocked while a request is sent to 

the node containing the desired resouroe 
Control message number 1 1 sent from Phoenix to Boston 
representing a remote resource request 
note After receipt of the remote resource request, Boston will send 
note two OBPL's to Cambridge because two processes In that node have 
note shared use of dbo2 in Boston. A third external message is not 
note needed because the third reader of dbo2 is located in Boston 
note and is active. We will delay the receipt of one of the OBPL's 
note until after the process in the list that controls dbo2 gets 
note blocked waiting for a resource located in Phoenix. 



resource request 



representing a remote resource allocation 



representing a remote resource request 



to Cambridge 



rcvcm 1 1 

Control message number 1 1 

has been received 
Resource is not currently available for exclusive use, process p1 

at node Phoenix remains blocked 
Control message number 12 sent from Boston 

representing an OBPL 
Control message number 13 sent from Boston 

representing an OBPL 
rcvcm 12 

Control message number 12 representing an OBPL 
rqdbo shared Cambridge p1 Boston dbol 

Process p1 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 14 sent from Cambridge to Boston 

representing a remote resource request 
rqdbo shared Cambridge p2 Phoenix dbol 

Process p2 at node Cambridge is blocked while a request is sent to 

the node containing the desired resource 
Control message number 15 sent from Cambridge 

representing a remote resource request 



to Cambridge 



has been received. 



to Phoenix 
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to Cambridge 



revem 13 

Control message number 13 representing an OBPL has been reoeived. 

Control message number 16 sent from Cambridge to Phoenix 
representing an OWL ^ 

note Let Phoenix receive the; OBPL before it receives the remote resource 
note request that was assumed to have taken oAaoe before the last 
note process was added to the OBPL. Jbe^QJiPL «£: irded because 
note Phoenix has no reoord that p2 in Cambridge is waiting for dbol 
note in Phoenix, 
rcvcm 16 

Control message .number 16 representing an OBPL has been reoeived. 
note Now let the above mentioned remote resource request be received 
note by Phoenix. An OBPL will be oreated and sent to Cambridge, which 
note will, then discard the OBPL because pj. is motive, 
rcrcm 15 

Control message number 15 representing a remote resource request 
has been received 

representing an OBPL 
rcvom 17 

Control message number, 17 representing anjOBPL haa been received, 
note Row let the remote resource request for dbol in Boston by p1 in 
note Cambridge be received by Boj «PL will be created and sent 
note to Pj&enix, where p2 in' Phoenix is wsHing for 4bol in Phoenix, so 
note the OBPL will be passed on to Cambridge; where pITis active, and 
note the OBPL will then be discarded, 
rcvom 11 

Control message number 14 representing a remote resource request 
has been received 

Resource not available, process remains blocked. 

Control message number 18 sent from Bos-ton 
o representing aa OBPV 
rcvcm 18 ; 

Control message number 18 representing an OBPL 
rqdbo exclusive Phoenix pa Phoenix dbol 

Resource not svailabl* , process blocked , 

Control message number 19 »tot from Phoenix 

note The OBPL will be discarded by Cambridge because p3 is active, 
rcvcm 19 
Control message number 19 representing ah OBPL 



to Phoenix 



has been received. 



to Cambridge 



note 
note 
note 
note 
note 
note 
note 
note 



The next command will oreate a two 

An OBPL will be sent to Phoei 

to the OBPL and send the OBPL baap. 

for dbo2 in Beaton. The deadloWr wi 

OBPL*i will be sent to Cambridge because t 



has been received. 

tup resource deadlock, 
d pi in Phoenix 
use- pi is waiting 

_.„#ec*ee;^end'tw© ■ 
fe^are'-'tillee readers 




of dbo2. These OBPL's will then be passed around until they 



return to Cambrid 



rcvmsg mg1 
Prooess 



Cambridge will st 



Ill 



where they will be dj 

be. /: aet|ve::<wlien;: the 



rded because p3 in 
L'Ssget examined. 



pi at node Boston 

message in message group ag1 
Control message number 2o sent from Boston 
representing an OBPL 
rcvcm 20 
Control message number 20 representing an OBPL 
Control message number 21 sent from Phoenix 
representing sn OBPL 



is b looked waiting for a 



to Phoenix 



has been reoeived. 
to Boston 
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representing an OBPL 
sent from Cambridge 



has been received, 
to Cambridge 



to Cambridge 



has been received, 
to Boston 



has been received, 
to Phoenix 



has been received, 
to Cambridge 



has been received. 

has been received, 
to Phoenix 



has been received, 
to Cambridge 



rcvcm 21 

Control message number 21 representing an OBPL 
Control message number 22 sent from Boston 

representing an OBPL 
A deadlock has been detected. The following processes are involved: 

p1 at node Boston 

pi at node Phoenix 

End of deadlock list 
Control message number 23 sent from Boston 
representing an OBPL 
rcvcm 22 

Control message number 22 representing an OBPL 
Control message number 2M sent from Cambridge 
representing an OBPL 
rcvcm 2h 

Control message number 24 representing an OBPL 
Control message number 25 sent from Boston 
representing an OBPL 
rcvcm 25 

Control message number 25 representing an OBPL 
Control message number 26 sent from Phoenix 
representing an OBPL 
rcvcm 26 

Control message number 26 representing an OBPL 
rcvcm 23 

Control message number 
Control message number 

representing an OBPL 
rcvcm 27 

Control message number 27 representing an OBPL 
Control message number 28 sent from Phoenix 
representing an OBPL 
rcvcm 28 

Control message number 28 representing an OBPL has been received, 
note This next request will create two deadlocks. An OBPL will be 
note sent to Phoenix, which will add p1 in Phoenix to the list and 
note send it to Boston. Boston will then send out three OBPL'S, 
note one for each reader of dbo2 in Boston. These OBPL's will be 
note passed among the various nodes until there are no more OBPL's 
note and control messages outstanding. Note that the two process two 
note resource deadlock will be detected for a second time because of 
note the fact that p1 in Boston still has shared access to dbo2 in 
note Boston and the deadlook has not been broken by aborting any 
note processes. 

rqdbo exclusive Cambridge p3 Cambridge dbol 
Resource is not currently available for exclusive use, process p3 

at node Cambridge is blocked. 
Control message number 29 sent from Cambridge 
representing an OBPL 
rcvcm 29 

Control message number 29 representing an OBPL 
Control message number 30 sent from Phoenix 
representing an OBPL 
rcvcm 30 

Control message number 
Control message number 

representing an OBPL 
Control message number 32 sent from 

representing an OBPL 
Control message number 33 sent from Boston 
representing an OBPL 
rcvcm 32 

Control message number 32 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

p1 at node Phoenix 

p1 at node Boston 

End of deadlock list 



SO representing an OBPL 
11 sent from Boston 



Boston 



to Phoenix 



has been received, 
to Boston 



has been received, 
to Cambridge 

to Phoenix 

to Cambridge 
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rcvcm 31 

Control message number 31 representing an OBPL 
Control message number 34 sent from Cambridge 
representing an OBPL 

revom 34 

Control message number 34 representing an OBPL 
Control message number 35 sent from Boston 
representing an OBPL 

rcvcm 35 
Control message number 



has been received, 
to Boston 



has been received, 
to Phoenix 



35 representing an OBPL has been received. 



The following processes are involved: 



at node 
at node 
at node 
at node 



Cambridge 
Phoenix 
Cambridge 
Phoenix 



A deadlock has been detected. 

p l 

p2 
End of deadlock list 
rcvcm 33 

Control message number 33 representing an OBPL 
Control message number So sent from Cambridge 
representing an OBPL 
rcvcm 36 

Control message number 36 representing an OBPL has been received. 
A deadlock has been detected. The following processes are involved: 

P3 at node Cambridge 

p1 at node Phoenix 

„ J „ _, p2 at node Cambridge 

End of deadlock list 



has been received, 
to Phoenix 
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resource request 



resource allocation 



scenario demoQ 

note This is an example of a case where a process releases a remote 
note database object and sends a remote resource control message at 
note the same time that an OBPL is sent to this node stating that some 
note other process is waiting for the resource mentioned above, which 
note is controlled by the first process mentioned above. Before the 
note OBPL arrives, the first process gets blocked waiting for a resource 
note that is controlled by the process that was placed in the OBPL. 
note No deadlock is detected because the resource in question is no 
note longer controlled by the last process to be added to the OBPL. 
rqdbo shared Boston p1 Phoenix dbol 

Process p1 at node Boston is blocked while a request is sent to 

the node containing the desired resource 
Control message number 1 sent from Boston to Phoenix 
representing a remote resource request 
rcvcm 1 

Control message number 1 representing a remote 

has Been received 
p1 at node Boston is granted shared access to 

dbol at node Phoenix 
Control message number 2 sent from Phoenix to Boston 
representing this allocation 
rcvcm 2 

Control message number 2 representing a remote 

has been received 
p1 at node Boston has been granted shared access to 

dbol at node Phoenix 
rqdbo exclusive Phoenix p1 Boston dbol 

Process p1 at node Phoenix is blocked while a request is sent to 

the node containing the desired resource 
Control message number 3 sent from Phoenix to Boston 
representing a remote resource request 
rcvcm 3 

Control message number 3 representing a remote 

has been received 
pi at node Phoenix is granted exclusive use of 

dbol at node Boston 
Control message number 4 sent from Boston to Phoenix 
representing this allocation 
rcvcm U 

Control message number U representing a remote 

has been received 
p1 at node Phoenix has been granted exclusive use of 

dbol at node Boston 
rqdbo shared Boston p1 Boston dbol 

Resource not available, process blocked. 

Control message number 5 sent from Boston to Phoenix 
representing an OBPL 
note Let dbol in Boston be released by p1 in Phoenix, and let p1 in 
note Phoenix then get blocked waiting for dbol in Phoenix before the 
note OBPL from Boston is received by Phoenix, 
rldbo Phoenix p1 Boston dbol 

Control message number 6 sent from Phoenix to Boston 
representing a remote resource release 
rcvcm 6 

Control messa, 
has 



resource request 



resource allocation 



resource release 



dbol 
Process 



P1 
dbol 



?e number 6 representing a remote 
been received 
at node Boston has been released by 

at node Phoenix 

at node Boston is granted shared access to 

at node Boston 



rqdbo exclusive Phoenix p1 Phoenix dbol 

Resource is not currently available for exclusive use, process p1 

at node Phoenix is blocked. 
Control message number 7 sent from Phoenix to Boston 

representing an OBPL 
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rcvcm 7 

Control message number 7 representing an OBPL has been received, 
note No deadlock will be detected because Phoenix observes that p1 in 
note Phoenix no longer has access to dbol in Boston, and discards 
note the OBPL. 
rcvcm 5 

Control message number 5 representing an OBPL has been received. 




Boston 



Phoenix 



State where control message 5 has just been sent from Boston to Phoenix. 
Control message 5 represents an OBPL. Receipt of the OBPL is delayed until 
after the state drawn below is reached. 




shared 




Boston 



Phoenix 



Final State Diagram 
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note 
note 
note 
note 
note 
note 
note 
note 
note 
note 



Phoenix 



resource request 



This is an example where an OBPL is sent from Boston to Phoenix 
stating that a process in Boston is waiting for a message from a 
process in Phoenix. Before the OBPL arrives in Phoenix, the 
desired message is sent, and the process in Phoenix gets blocked 

n?aH3 g <£ r* a £Sm U rSV hat is controlled by the process that was 
placed in the OBPL that was sent from Boston to Phoenix. No 
deadlock is detected because Phoenix notices that the message 
that was desired by the process* in Boston has already been sent. 
The first six commands create the state where the OBPL 
.-:: mentioned above has just been sent, 
initmg mg1 Phoenix pi Boston 

Message group mg1 has been initiated 
accepting mg1 Boston p1 

mgl has been accepted by p1 at node Boston 
rqdbo exclusive Boston p1 Phoenix dbol 

Process pi at node Boston is blocked while a request is sent to 

the node containing the desired resource 
Control message number 1 sent from Boston to 
representing a remote resource request 
rcvcm 1 M 

Control message number 1 representing a remote 

has been received 
P 1 .. , at node Boston is granted exclusive use of 
_ ^ , dbol at node Phoenix 

Control message number 2 sent from Phoenix to Boston 
representing this allocation 
rcvcm 2 

Control message number 2 representing a remote resource allocation 

has been received 
p1 .. , at node Boston has been granted exclusive use of 
. db °> at node Phoenix 
rcvmsg mg1 

Process pi at node Boston is blocked waiting for a 

message in message group mg1 
Control message number 3 sent from Boston to Phoenix 

representing an OBPL 

«°if c e aU now temporarily delay receipt of the OBPL by Phoenix, 
note Send the message that the process in Boston desires. rnoenix - 
sendmsg mgl 

Control message number H sent from Phoenix to Boston 
„««.« t Representing a message in a message group 
note Let the process in Boston receive the message, 
rcvcm i 

Control message_number 4 representing a message in a message group 

has been received 
Process pi at node Boston has been awakened upon 

,*, reeei St of a message in message group m«1 

not! H}?? 1c kE 1 in ? noenix and then let Boston disoard the OBPL that 
note will be created as a result of this wait, 
rqdbo shared Phoenix p1 Phoenix dbol 

Resource not available, process blocked. 

Control message number 5 sent from Phoenix to Boston 
representing an OBPL 
rcvcm 5 

Control message number 5 representing an OBPL has been received. 
notl Bo'stJn Phoenix rece ive the OBPL that was previously sent by 

rcvcm 3 

Control message number 3 representing an OBPL has been received. 
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exclusive 



Boston 




Phoenix 



State where control message 3 representing an OBPL has just been sent 
from Boston to Phoenix. Receipt of the OBPL is delayed until after the st 
drawn below is reached. 



tate 




exclusive 



Boston 




Phoenix 



Final State Diagram 
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scenario demo11 

note This is an example of a deadlock involving one process and one 
note operator at the same node. Two operator connections are involved, 
dclop Boston op1 

op1 has been declared as an operator at node Boston 
copcon conl Boston op1 p1 

Operator connection conl has been established 
copcon con2 Boston opl p1 

Operator connection con2 has been established 
note Let p1 in Boston request a message from operator op1 in Boston 
rcvopmsg conl , M 

Process p1 at node Boston is blocked waiting for a 

message over operator connection conl 
An OBPL has been queued waiting for a status report from operator opl 

at node Boston The involved operator connection is conl 
note Create a deadlock by reporting that opl is waiting for a message 
note over operator connection con2. 
opstat Boston opl waiting con2 

We will now check for deadlock involving the given operator 

and operator connection 
A deadlock has been detected. The following processes are involved: 

p1 at node Boston 

opl at node Boston 

End of deadlock list 




Boston 



Final State Diagram 
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scenario demo 12 

This is an example of a deadlock across three nodes which involves 
several operator connections. It demonstrates that deadlock 
involving operators will be detected as long as the operator 
properly states what he is waiting for. The first 15 commands 
set up the state where all operators have been declared, all 
operator connections have been created, the message group has 
been initiated and accepted, and the involved database objects 
have been assigned to the proper processes. 



at node Boston 
at node Phoenix 
at node Boston 



conl 

P2 a 
con2 



has been established 
has been established 
has been established 



con** has been established 



has been established 
has been established 



Phoenix 



note 
note 
note 
note 
note 
note 
note 
note 
dclop Boston op1 

op1 has been declared as an operator 
dclop Phoenix op1 

opl has been declared as an operator 
dclop Boston op2 

op2 has been declared as an operator 
copeon conl Boston op1 p1 

operator connection 
copeon con2 Boston op1 
Operator connection 
copeon con3 Boston op2 p2 

Operator connection con3 
copeon conl Boston op2 p3 

Operator connection 
coDcon con5 Phoenix op1 p2 

Operator connection con5 
copeon con6 Phoenix op1 p1 

Operator connection con6 

initmg mg1 Cambridge p1 Phoenix 

Message group mg1 has been initiated 
acceptmg mgl Phoenix p1 

mg1 has been accepted by p1 at node 
rqdbo exclusive Boston p3 Cambridge dbol 

Process p3 at node Boston is blocked while a request is sent to 

the node containing the desired resource 
Control message number 1 sent from Boston to Cambridge 
representing a remote resource request 
revcm 1 

Control message number 1 representing a remote resource request 
has been received 

at node Boston is granted exclusive use of 
dbol at node Cambridge 
Control message number 2 sent from Cambridge to Boston 
representing this allocation 
revem 2 

Control message number 2 
has been received 

at node Boston has been granted exclusive use of 
dbol at node Cambridge 
rqdbo shared Phoenix p2 Phoenix dbol 

at node Phoenix granted shared access to dbol at node Phoenix 
Let p1 in Boston wait for exclusive use of dbol in Phoenix. No 
deadlock will be detected because p2 in Phoenix, which controls 
dbol in Phoenix, is active, 
rqdbo exclusive Boston pi Phoenix dbol 

Process p1 at node Boston is blocked while a request is sent to 

the node containing the desired resource 
Control message number 3 sent from Boston to Phoenix 
representing a remote resource request 
revem 3 

Control message number 3 representing a remote resource request 

has been received 
Resource is not currently available for exclusive use, process pi 
at node Boston remains blocked 



P3 



representing a remote resource allocation 



P3 



P2 
note 
note 
note 
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note Let p2 in Phoenix now wait for a message from op1 in Phoenix, 
note We then state that op1 in Phoenix is active, so no OBPL's get 
note expanded further, 
rcvopmsg con5 

Process p2 at node Phoenix is blocked waiting for a 

message over operator connection con5 
An OBPL has been queued waiting for a status report from operator op1 

at node Phoenix The involved operator connection is con5 
opstat Phoenix op1 active 

All OBPL's waiting for the given state information have been discarded 
note Let p1 in Phoenix wait for a message from p1 in Cambridge. No 
note deadlock exists because p1 in Cambridge is active, 
rcvmsg mg1 

Process p1 at node Phoenix is blocked waiting for a 

message in message group mg1 
Control message number 4 sent from Phoenix to Cambridge 
representing an OBPL 
rcvcm 4 

Control message number 4 representing an OBPL has been received, 
note Let p3 in Boston wait for a message from op2 in Boston. The 
note OBPL created when p3 gets blocked will be discarded when we 
note state that op2 is active, 
rcvopmsg con4 

Process p3 at node Boston is blocked waiting for a 

message over operator connection con4 
An OBPL has been queued waiting for a status report from operator op2 
at node Boston The involved operator connection is con4 
opstat Boston op2 active 

All OBPL's waiting for the given state information have been discarded 
note Simultaneously block p1 in Cambridge and p2 in Boston. Then 
note let Boston receive the OBPL from Cambridge that was created 
note when p1 in Cambridge was blocked. Before we report the status 
note of op1 in Boston, state that op2 in Boston is waiting for a 
note message from p2 in Boston, thereby queuing a second OBPL for 
note information on the status of op1 in Boston, 
rqdbo shared Cambridge p1 Cambridge dbol 
Resource not available, process blocked. 
Control message number 5 sent from Cambridge 
representing an OBPL 
rcvopmsg con2 

Process p2 at node Boston is blocked waiting for a 

message over operator connection con2 
An OBPL has been queued waiting for a status report from operator opl 

at node Boston The involved operator connection is con2 
rcvcm 5 

Control message number 5 representing an OBPL has been received. 

An OBPL has been queued waiting for a status report from operator op2 

at node Boston The involved operator connection is eon4 
opstat Boston op2 waiting con3 

We will now check for deadlock involving the given operator 

and operator connection 
An OBPL has been queued waiting for a status report from operator op1 

at node Boston The involved operator connection is con2 
opstat Boston op1 waiting conl 

We will now check for deadlock involving the given 

and operator connection 
Control message number 6 sent from Boston 

representing an OBPL 
Control message number 7 sent from Boston 
representing an OBPL 
note There were two OBPL's waiting for state information from op1 in 
note Boston, therefore two OBPL's are expanded and sent to Phoenix, 
note Let Phoenix receive and expand both OBPL's, and state that op1 
note in Phoenix is waiting for a message from pi in Phoenix, thereby 
note closing the deadlock loop. The deadlock will be detected twice 
note because we had two OBPL's being passed around due to the fact 
note that we blocked two processes simultaneously. 
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to Phoenix 
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rcvcm 6 

Control message number 6 representing an OBPL has been received. 

An OBPL has been queued waiting for a status report from operator op1 

at node Phoenix The involved operator connection is con5 
rcvcm 7 

^"^ES. 1 messa 8 e number 7 representing an OBPL has been received. 
An OBPL has been queued waiting for a status report from operator opl 
.. «. «w a P nod ? Phoenix The involved operator connection is con5 
opstat Phoenix op1 waiting con6 

We will now check for deadlock involving the given 

and operator connection 
Control message number 8 sent from Phoenix 

representing an OBPL 
Control message number 9 sent from Phoenix 
representing an OBPL 
rcvcm 8 

Control message number 8 representing an OBPL has been received. 
Control message number 10 sent from Cambridge to Boston 
representing an OBPL 
rcvcm 9 

Control message number 9 representing an OBPL has been received. 



operator 

to Cambridge 

to Cambridge 



The following processes are involved: 



at node 
at node 
at node 
at node 
at node 
at node 
at node 
at node 
at node 



Cambridge 

Boston 

Boston 

Boston 

Boston 

Boston 

Phoenix 

Phoenix 

Phoenix 



A deadlock has been detected 

p3 o 
op2 

p2 

opl 

P I 

p2 i 
op1 

p1 

End of deadlock list 
rcvcm 10 

Control message number 10 representing an OBPL has been received. 
An OBPL has been queued waiting for a status report from operator op2 
^ ^ „ ^ at no 2 e Boston The involved operator connection is conH 
opstat Boston op2 waiting con3 

We will now check for deadlock involving the given operator 

and operator connection 
A deadlock has been detected. The following processes are involved: 

p2 at node Boston 

op1 at node 

p1 at node 

p2 at node 

op1 at node 

p1 at node 

p1 at node 

p3 at node 

op2 at node 

End of deadlock list 



Boston 

Boston 

Phoenix 

Phoenix 

Phoenix 

Cambridge 

Boston 

Boston 
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